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Monograph Series on Advanced Computing Systems 


The USENIX Association intends to pub¬ 
lish books and monographs on the general 
topic of computing systems. The intended au¬ 
dience for these books is the community of 
system designers, builders, users, and scholars. 
Our intent is to publish material of lasting in¬ 
terest and importance, with an emphasis on 
actual systems. Subjects may include design, 
implementation, history, and analysis of real 
systems. While we are inspired by UNIX and 
UNIX-like systems, we do not expect to limit 
our attention to such systems in any way, as 
we see ourselves responsible to the entire 
systems community. 

We see several specific needs that we 
would like to satisfy and for which we solicit 
manuscripts. The needs fall in two areas - 
books in traditional styles and formats about 
topics important to the systems community 
and things new or unusual. 

Among things new or unusual, we are in¬ 
terested in exploring at least these ideas: 

Significant systems - Many significant systems 
are documented, if at all, only in reference 
manuals or user guides. Journal publications 
often concentrate on narrow specific details, as 
is appropriate for focused technical audiences. 
What is lost is the broad description of the 
design and its evolution, with consideration of 
the success and failure of specific features and 
lessons learned. 

Code - We are interested in exploring the pos¬ 
sibilities of publishing code to read. A truism 
among the programming community is that 
one learns to write good programs by reading 
good and bad programs. Sadly, there is little 
code available to read. The recent interest in 
public-domain code and open systems has in¬ 
creased the quantity of high-quality source 
code available. Many open questions in the 
publication of code remain to be explored. 


The conventional codex form, long accepted as 
appropriate for literary works and texts, may 
not be the right one for programs. Very few 
experiments have been made with this form, 
something that we hope to encourage. The au¬ 
dience for published code includes serious 
students of systems, including both the under¬ 
graduate and advanced levels, and practition¬ 
ers involved with development, modification, 
and analysis of actual systems. 

Important technical reports - Many important 
technical reports, issued in small numbers by 
industrial organizations, research labs, or 
university departments, are not disseminated 
as widely as they merit. This is often because 
the originating organization doesn’t have the 
resources or the will to publish them more 
widely and because the material is deemed 
inappropriate by commercial publishers 
because of its narrow scope or limited size. 
Many technical reports are too large for jour¬ 
nal publication and too small for conventional 
book publication. We hope to provide a 
means of publication and distribution of the 
best of these. 

Authors will enter into a contractual 
arrangement with USENIX. The Association is 
in the process of selecting a publisher to han¬ 
dle marketing and distribution. We hope that 
you will consider this arrangement a viable op¬ 
tion for your next manuscript. 

To submit a manuscript or proposal for 
consideration for the Monograph series, send a 
copy to: 

Monograph Editor 
USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 

or send electronic mail to 

monographs@usenix.org. 
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UNIX Security Workshop 

Marriott Hotel, Portland, OR, August 27-28, 1990 

The Second USENIX UNIX Security Workshop will be held in Portland, Oregon on Monday and 
Tuesday, August 27-28, 1990. The workshop is organized to bring researchers, system administrators, 
and others together to discuss their needs and interests in the many aspects of computer security as 
they relate to the UNIX Operating System. 

This meeting will have elements of both a conference and a workshop; the former in that there 
will be presentations, the latter in that discussion and audience participation are expected. Speakers 
will discuss work in progress and/or work that is planned and will solicit opinions, comments, and 
suggestions from other participants. There will be at least three panel sessions. 

Tentative Program 

Monday, August 27 

9-10:30 Authentication I 

David Goldberg, MITRE 

The MITRE User Authentication System 

Daniel Klein, Software Engineering Institute, CMU 
A Survey of, and Improvements to, Password Security 

Matt Bishop, Dartmouth College 
An Extensible Password Changing Program 

Michele Crabb, NASA Ames Research Center 
Password Security in a Large Distributed Environment 

11-12 Potpourri I 

Maria Pozzo, UCLA Computer Science Dept. 

An Automatic Policy Checker for Controlling Undesirable Program Behaviors 
John Linn, DEC 

Generic Security Service Application Program Interface 

Henry Teng, DEC, and David Brown, Worcester Polytechnic Institute 
An Expert Systems Approach to Security Inspection of UNIX 

1:30-2:30 Secure Systems and Tools 

Raymond Wong, Oracle 
A Survey of Secure UNIX Operating Systems 

David Gill, MITRE 

Roles for Users and Privileges for System Processes: High Trust Mechanisms for Low Trust Systems 
Pat Bahn, GTE 

Beyond Bell-LaPadula: A Security Model for Real Applications 

3:00-5:00 Access Control 

Marshall Abrams, Leonard LaPadula, & Ingrid Olson, MITRE 
Building Generalized Access Control on UNIX 

David Wichers, ARCA Systems, and Douglas Cook, Ronald Olsson, John Crossley, Paul Kerchen, 

Karl Levitt, & Raymond Lo, University of California at Davis 
An Access Control List Approach to Anti-Viral Security 
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Frank Kardel, Friedrich Alexander University 
Frozen Files 

Hermann Strack, University of Karlsruhe 
to be arranged 

Panel and discussion on access control 

Tuesday, August 28 
9-10:30 Authentication II 

Ana Maria De Alvare, Lawrence Livermore National Laboratory 
How Crackers Crack Passwords 

Steven Lunt, Bellcore 
Experiences with Kerberos 

Joe Tardo, Kannan Alagappan, & Richard Pitkin, DEC 
Public Key-based Authentication using Internet Certificates 

Panel and discussion on authentication 

11-12 Security Considerations and the Environment 

Richard Neely, Ford Aerospace 

System Design and Verification for Secure Applications Under UNIX 
Gary Christoph, Los Alamos National Laboratory 

Security Considerations of Going to a UNIX Based Supercomputer Operating System 

Bjorn Satdeva, /sys/admin, inc. 
to be arranged 

1:30-3:15 Networked Systems 

Mark Carson, Janet Cugini, Sohail Malik, Mythili Kannan, & Wen-Der Jiang, IBM 
Networked UNIX without the Superuser 

Jeffrey Roth, Defense Logistics Agency 
Hardening Anonymous FTP 

Jerry Carlin, Pacific Bell 
Gateway Security Measures 

Eugene Schultz, Lawrence Livermore National Laboratory 
UNIX Network Naivete 

Panel and discussion on network security 

3:45-5 Potpourri II 

Fuat Baran, Howard Kaye, & Margarita Suarez, Columbia University 
Security Breaches: Five Recent Incidents at Columbia University 

Panel and discussion on security in Large installations 


Program Chair : Matt Bishop, Dept, of Mathematics & Computer Science, Dartmouth College 

Full-time students please note: a limited number of scholarships are available. For an application 
form contact office@usenix.org 

For registration information, contact USENIX Conference office soon. 


July/August 1990 
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Call for Papers: Winter 1991 USENIX Conference 


Dallas, Texas, January 21-25,1991 

USENIX seeks original papers which 
describe new and interesting work for the 
Winter 1991 Technical Conference. Papers 
which are accepted for this conference will be 
published in the conference proceedings and 
will be presented during the three days of tech¬ 
nical sessions. 

The previous conference had a theme 
which was retrospective in nature, so for this 
conference we look to the future. We would 
like to include papers that emphasize changes 
to operating systems and environments as we 
know them today. Thus, the theme is: 

What’s next: by the year 2010, evolution or 
revolution? UNIX derivative or something else? 

Appropriate topics include, but are not 
limited to: 

Operating systems of the future: 

Distributed Systems 
Real-time systems 
Object-Oriented systems 
Fault Tolerant Systems 
Multiprocessor and Multicomputer Systems 
Workstation Systems 
Systems for Novel Architectures 
Communications and Networking: 

Protocols 

Performance 

Administration 

Security 

Applications: 

Databases 

Transaction Processing 
Arts and Social Applications 
Novel Application Areas 
User Interfaces 
Human Factors 

Graphics and Window Systems 
Graphical User Interfaces 
Programming Environments and Languages 
Testing and Debugging 

All submissions will be considered. How¬ 
ever, thinly disguised product announcements 
are rarely accepted, nor are rehashes of previ¬ 
ous papers. 


We will require at least an abstract and an 
outline in a form that gives the committee 
confidence in the final paper. 

A submission should be 2-3 typewritten 
pages and include the following: 

1. Author names, addresses, telephone 
numbers, and E-mail addresses. 

2. Abstract: 100-300 words (half a page) to 
be included in the final paper. 

3. Outline: 1.5-3 pages, giving the major 
headings of the paper, plus a few sentences per 
section that give the major points that will be 
covered in that section in the final paper. 

4. References: List a few key references to 
other work on the topic, preferably to other 
people’s work. 

The following is a sample outline, which is 
not necessarily appropriate for all papers, but 
which illustrates the important topics. 

1. Introduction 
Background 

Introduce the problem to be solved; why is it 
important? 

Refer to previous work; make sure the com¬ 
mittee knows the wheel is not being reinvented 

2. How We Solved the Problem 

More details on the problem and its issues 

Design decisions and tradeoffs, and why they 
were made 

Implementation issues 

3. Evaluation 

Data, on performance, effort required 
How well does it work? 

What would we do differently? 

If it failed, why? and what can we learn from 
it? 

4. Conclusion 

Summarize the paper, emphasizing why it is 
important, and what was learned 
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5. References 

Please submit abstracts with outlines as 
soon as possible, and mail one hard copy and 
one electronic copy to the addresses below. 
The final deadline for receipt of submissions is 
August 13, 1990. Abstracts received after this 
deadline will not be considered. Notification 
of acceptance or rejection will be made by Oc¬ 
tober 3, 1990. Final camera-ready papers are 
due by November 14, 1990. 

The final paper should retain the 100-300 
word abstract, add illustrations (where 
needed), and citations to relevant literature. 
Only previously unpublished submissions will 
be considered. Final papers should contain 8- 
12 pages of single spaced typeset materials. 
All final papers must be submitted in a 
camera-ready format or electronic format (troff 
-ms if possible). Typewritten or dot-matrix 
output is not acceptable. For authors without 
access to a laser printer or typesetter, 
appropriate facilities will be provided by the 
program chair. 

Please send the hard copy of your submis¬ 
sion to: 

Lori S. Grob 
Dallas Conference 
USENIX Association 
2560 9th Street, Suite 215 
Berkeley, CA 94710 


To request additional information, please 
contact: 

Lori S. Grob 

Dallas USENIX Technical Program 

Chorus systdmes 

6, avenue Gustave Eiffel 

F78182 Saint-Quentin-en-Yvelines CEDEX 

France 

Internet: daIlas-conf@usenix.org 

UUCP: uunet!usenix!dallas-conf 

Telephone: +33(1) 30 57 00 22 

FAX: +33 (1) 30 57 00 66 

Please include your physical and electronic 
mail address in all correspondence. 

Program Committee: 

Lori S. Grob, Chair, Chorus systemes 
Steve Bourne, Sun Microsystems 
Marc Donner, IBM Research 
Tom Duff, AT&T Bell Laboratories 
Jan Edler, New York University 
Michel Gien, Chorus systdmes 
Barry Gleeson, Unisys Corp. 

Trent R. Hein, University of Colorado, Boulder 

Andrew Hume, AT&T Bell Laboratories 

Michael J. Karels, University of California, Berkeley 

Deborah K. Scherrer, mt Xinu 

Melinda Shore, mt Xinu 

Max Meredith Vasilatos, Open Software Foundation 
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IEEE COMPUTER SOCIETY 


Call for Participation: Symposium on Experiences with 
Distributed and Multiprocessor Systems (SEDMS) 


Atlanta, GA, March 21-22, 1991 

Sponsored by the USENIX Association in association with the NSF/Purdue/Florida Software 
Engineering Research Center, in cooperation with ACM SIGCOMM and SIGOPS (pending) 
and the IEEE-CS Technical Committees on Distributed Processing, Operating Systems, and 
Software Engineering. 


Goals 

The goal of this symposium is to bring 
together individuals who have built, are build¬ 
ing, or will soon build distributed and mul¬ 
tiprocessor systems, especially operating 
systems. The symposium will feature full 
presentations and (perhaps) panels on aspects 
of building, testing, debugging, and using these 
systems. We will provide a forum for in¬ 
dividuals to exchange information on their ex¬ 
periences, both good and bad, including ex¬ 
periences with coding aids, languages, distri¬ 
buted debugging tools, prototyping, reuse of 
existing software, performance analysis, and 
lessons learned from use of such systems. 
Extra-long breaks between sessions and work- 
in-progress presentations will be provided to 
facilitate a workshop-like atmosphere during 
the symposium. 

Submissions 

Ten copies of each submission or panel 
proposal should be sent to the program com¬ 
mittee chair (address below) to arrive no later 
than November 19, 1990. Submissions of full 
papers are invited on any topics related to the 
theme of the symposium. The committee will 
give preferential consideration to submissions 
describing experiences with actual systems - 
papers describing theoretical work or simula¬ 
tions are unlikely to be accepted. Panel 
proposals should include a description of the 
relevance to the goals of the SEDMS, and the 
qualifications of the participants suggested. 


Important Dates 

Submissions due Nov. 19, 1990 

Notifications mailed Jan. 7,1991 

Camera ready copy due Jan. 30, 1991 

For further information, contact: 

General Chair 

George Leach 
AT&T Paradyne 
MS LG-133 
PO Box 2826 
Largo, FL 34649-2826 

(813) 530-2376 
reggie@paradyne.com 

Program Chair 
Gene SpafFord 

Software Engineering Research Center 
Dept, of Computer Sciences 
Purdue University 
W. Lafayette, IN 47907-2004 

(317) 494-7825 
spaf@cs.purdue.edu 

Program Committee 

John Barr (Motorola, Inc.) 

Bharat Bhargava (Purdue University) 

David Cohn (Notre Dame) 

George Leach (AT&T Paradyne) 

Mike O’Dell (Bellcore) 

Karsten Schwan (Georgia Tech) 

Michael Scott (University of Rochester) 

Roger Shultz (Rockwell International) 

Gene SpafFord (Purdue University/SERC) 

Satish Tripathi (University of Maryland) 
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Long-Term Calendar of UNIX Events* 


1990 Aug 20-23 

Interex 

1990 Aug 27-28 

* Security 

1990 Sep 3-7 

DECUS Europe Symposium 

1990 Sep 4-6 

GUUG 

1990 Sep 25-28 

AUUG 

1990 Oct 4-5 

*Mach 

1990 Oct 8-12 

InterOp 90 ACE 

1990 Oct 15-19 

IEEE 1003 

1990 Oct 17-19 

* Large Installation Sys. Admin. 

1990 Oct 22-26 

EUUG 

1990 Oct 29-Nov 2 

Soviet UNIX Users’ Group 

1990 Oct 31-Nov 1 

UNIX Expo 

1990 Nov 5-9 

Computer Communication Conf. 

1990 Nov 8 

Open Systems, NLUUG 

1990 Nov 14-16 

UNIX EXPO ’90 UniForum 

1990 Nov 15 

POSIX APP Workshop 

1990 Nov 15-16 

16th JUS Symposium 

1990 Dec 2-6 

Sun User Group 

1990 Dec 4-5 

JUS UNIX Fair ’90 

1990 Dec 10-12 

UNIX Asia ’90 

1990 Dec 10-14 

DECUS 

1990 Dec 17-19 

UKUUG 


Boston, MA 

Portland, OR 

Cannes, France 

Wiesbaden, Germany 

World Congress Centre, Melbourne, Aust. 

Burlington, VT 

San Jose, CA 

Seattle, WA 

Colorado Springs, CO 

Nice, France 

Moscow, USSR 

New York, NY 

ICCC; New Delhi, India 

Ede, Netherlands 

Stockholm, Sweden 

NIST; Gaithersburg, MD 

Osaka, Japan 

San Jose, CA 

Tokyo, Japan 

Sinix, Singapore 

Las Vegas, NV 

Cambridge, UK 


1991 Jan 7-11 

IEEE 1003 

1991 Jan 16-18 

* Software Devel. Environments 

1991 Jan 21-25 

USENIX 

1991 Jan 22-25 

UniForum 

1991 Feb 

UNIX in Government 

1991 Feb 18-22 

DECUS 

1991 Mar 21-22 

* Symp. Distrib. Multiproc. Sys. 

1991 Apr 15-19 

IEEE 1003 

1991 May 

UNIX 8x/etc 

1991 May 6-10 

DECUS 

1991 May 20-24 

EUUG 

1991 Jun 10-14 

USENIX 

1991 Jun 16-19 

Sun User Group 

1991 Jul 8-12 

IEEE 1003 

1991 Jul 15-17 

UKUUG 

1991 Sep 16-20 

EUUG 

1991 Oct 21-25 

IEEE 1003 

1991 Dec 

UKUUG 

1991 Dec 8-11 

Sun User Group 

1991 Dec 9-13 

DECUS 


New Orleans, LA 
Grand Kempinski, Dallas, TX 
Grand Kempinski, Dallas, TX 
Infomart, Dallas, TX 
Ottawa, Ont. 

Ottawa, Ont. 

Atlanta, GA 
Houston, TX 

/usr/group/cdn; Toronto, Ont. 
Atlanta, GA 
Tromso, Norway 
Opryland, Nashville, TN 
Atlanta, GA 

Santa Clara, CA (tentative location) 

Liverpool, UK 

Budapest, Hungary 

Southern Europe (location tentative) 

Edinburgh, UK 

San Jose, CA 

Anaheim, CA 


1992 Jan 13-17 
1992 Jan 20-24 
1992 Jan 21-24 
1992 Spring 
1992 Apr 20-24 
1992 May 4-8 
1992 Jun 8-12 
1992 Jun 21-24 
1992 Autumn 


IEEE 1003 

USENIX 

UniForum 

EUUG 

IEEE 1003 

DECUS 

USENIX 

Sun User Group 

EUUG 


Orlando, FL (location tentative) 
Hilton Square, San Francisco, CA 
Moscone Center, San Francisco, CA 
Jersey, UK 
Montreal, Que. 

Atlanta, GA 

Marriott, San Antonio, TX 
Washington, DC 
Amsterdam, Netherlands 


t Compiled with the assistance of Alain Williams of the EUUG, Susanne Smith of Windsound Consulting, and John 
Quarterman of Texas Internet Consulting. 

* USENIX Workshops 
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Report from the Anaheim Conference 


Best Student Paper 

The Program Committee named Paul 
Haahr of Princeton as the author of the best 
student paper at the conference. Haahr’s pa¬ 
per, “Montage: Breaking Windows into Small 
Pieces” was presented at the 1990 Summer 
USENIX Conference in Anaheim, California. 


Work in Progress Session 

Lisa Bloch , Chair 

Bjorn Satdeva, /sys/admin, inc. 

Automatic Lazy File Distribution in a 
Heterogeneous System Environment Using a 
Domain Style Approach 

MIPS, like many other large sites, has, in 
the past, used rdist to provide an automatic 
distribution of system configuration files to a 
number of hosts. However, since the require¬ 
ments for distribution of files to various sub¬ 
sets of hosts continues to change over time, it 
has become very inconvenient to use rdist for 
this purpose in a reliable and systematic 
manner. 

The fdist software has been developed to 
allow easy and simple configuration of such a 
distribution. A file can be distributed to a well 
defined subset of hosts, using a logical domain 
naming scheme similar to the one used by the 
Internet. A modified rdist is used for the 
underlying distribution. 

Each host can be part of one or more 
domains. A host can, for example, be part of 
one domain showing which department is us¬ 
ing the host, and another domain dependent 
on its geographical location. To support this, 
fdist provides a number of “top domains,” 
each representing a view of the site. For each 
top domain, it must be specified which second 
level domain the host belongs to, as well as the 
operating system and hardware platform. 

As an example, a host is in the “adm” 
(administrative) top domain and the “hdwgrp” 
(hardware group) second level domain. The 


OS is “bsd” (BSD 4.3) and the hardware is 
“mips.” This host would be included in 
domain references like “hdwgrp.adm” or 
“mips.bsd.hdwgrp.adm.” 

To distribute a file hourly, the following 
command will update the fdist data files, as 
well as save a copy of the file: 

fdist -o add source-file \ 

bsd.hdwgrp.adm:/etc/services hour 

John Kohl, DEC & MIT Project Athena 
Kerberos Version 5 Update 

Kerberos version 5 is a revision and reim¬ 
plementation of the widely available version 4 
protocol. This talk will briefly touch on the 
goals of a Kerberos authentication exchange, 
and spend the main portion of the presenta¬ 
tion on the differences between v4 and v5 and 
some compatibility issues. 

A Kerberos exchange achieves the authen¬ 
tication of a client to a network server and a 
secure exchange of an encryption key between 
them, using a three message exchange. It can 
also provide authentication of the server to the 
client if desired, at the cost of an additional 
message. 

An implementation of Version 4 of the 
protocol has been widely available in the Inter¬ 
net community since January 1989. Some 
concerns raised about the capabilities of V4 
led to the discussion and draft specification of 
Version 5 protocol during late 1989. The 
major differences between the two versions’ 
protocols are: 

• The principal names in V5 are multi- 
component rather than three components as 
found in V4. 

• V5 adds new flags in the ticket (more 
detail below). 

• V5 adds support for a new authentication 
mode which does not require secure long-term 
possession of a secret key by a server (this is 
referred to as the user-to-user authentication 
mode). 
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• The encryption system may be replaced in 
V5. 

• The network address types may be re¬ 
placed in V5. 

• The V5 ticket adds flags to support vari¬ 
ous new functions: Forwarding, proxying, and 
post-dating tickets; renewing tickets; indicating 
method of ticket issue; and duplicating session 
keys. 

• The user-to-user authentication mode util¬ 
izes a user’s ticket-granting ticket (TGT) and 
its session key as a basis for the trust of a 
server to participate in an authentication ex¬ 
change; this reduces the burden on the server 
host to keep secrets for long periods of time. 
The client requests this ticket from the server, 
forwards it along with his own TGT to the 
Kerberos server, and the server responds with 
a ticket usable by the server but encrypted in 
the server’s TGT’s session key. 

• The encryption system used in V5 can be 
replaced by indicating a different encryption 
type in the protocol messages; the receiver 
then uses an alternate encryption method to 
decrypt the message. The network addresses 
are similarly tagged with a type field and a 
length. 

The MIT implementations of V4 and V5 
differ; V5 is a complete rewrite from scratch, 
utilizing distinct function and data names (so 
that V4 and V5 code may be linked into a sin¬ 
gle application), a more flexible interface to 
the pieces which are likely to need reimple¬ 
mentation for porting, and eventually a 
“Generic” API to allow an application 
programmer to ignore the details of the under¬ 
lying system. The V5 Kerberos server imple¬ 
mentation will support V4 requests to provide 
a smooth migration path. 

MIT’s V5 code is still under development, 
but will be made available under terms similar 
to the X distribution terms. 

Dan Geer, Digital Equipment Corporation & 
Cambridge Research Laboratory 
New Platforms for Researchers 

A project to put together several of the 
best available research vehicles is described. 


The Athena network services environment (in¬ 
cluding Kerberos version 5), a synthesis of 
Mach 3.0, Ultrix 4.0, and several other 
leading-edge tools, will be available late this 
summer to qualified research organizations. 

Richard Campbell, University of Michigan 
Center for Information Technology Integration 
Institutional File System Project 

The Institutional File System project is a 
joint University of Michigan and IBM research 
effort to develop a highly scalable, high perfor¬ 
mance distributed file system. Taking 
Transarc’s AFS as a base, we are porting the 
file server to various mainframe platforms 
(such as AIX/370, MVS/ESA, VM/CMS), creating 
servers that translate other file system pro¬ 
tocols (such as Sun NFS and Apple AFP) to 
AFS, and writing an intermediate server to 
facilitate local caching. A network of 
mainframe servers, intermediates, and transla¬ 
tors is anticipated to reliably serve tens of 
thousands of workstation-class machines with 
a centrally managed and secure file system. 
Several of these servers are currently in pro¬ 
duction use on our project and are about to 
undergo field test followed by deployment to 
the university campus. Future plans include 
designing additions to the protocols to support 
the needs of supercomputing sites, investigat¬ 
ing other mass storage and backup systems, 
and writing translators for other protocols. 

Contact info@ifs.umich.edu or (313) 763- 
4403 for further information. 

Landon Noll, Pyramid Technology & 

Group 70 

Remote Controlled Telescopes 

Group 70, the non-profit organization 
hoping to build the world’s largest amateur- 
built telescope, has received its 72-inch glass 
mirror blank. It arrived from Tasmania after 
a six week journey. The goal of the project is 
to create a professional-class instrument which 
can be operated remotely so that many people 
can use it, including amateur and professional 
astronomers, educational institutions, and 
students. Currently the team expects to com¬ 
plete the project in seven years. In the face of 
declining government funding of professional 
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astronomy, private initiatives, such as Group 
70, are becoming more important to the 
progress of the science of astronomy. 

The design is well under way and will 
feature the latest technology to automatically 
control the telescope and capture images elec¬ 
tronically. This will allow the telescope to be 
operated remotely, which should make it 
easier for many people to use it. The goal is 
to make a professional-class instrument avail¬ 
able to the general public. Currently, only a 
few hundred people in the world get access to 
an instrument of this size. With remote opera¬ 
tion and imaging, it should be available to 
anyone with a computer. This challenging 
goal will push the project to limits of technol¬ 
ogy in telescope control, facilities control, 
computer networking, and image storage and 
display. 

The telescope will be an f/10 classical 
Cassigrain with an f/3 primary mirror. The 
“tube” will be an open metal frame and will 
be mounted on an altazimuth mount. Several 
types of instruments will be available at any 
one time, possibly including a CCD electronic 
imager, a spectrograph, and a photometer. 
The general purpose design will allow observa¬ 
tion of planets, variable stars, nebulae, and 
deep space objects like galaxies. 

For more information call (415) 654-6796, 
or write Group 70, 2331 American Ave., Hay¬ 
ward, CA 94545. 


Sony Watchman Winner!! 

DATAPRO held a drawing for a Sony 
Watchman at the conclusion of the Summer 
1990 USENIX Technical Exhibition in 
Anaheim. The winner was Bruce A. Hamilton 
of the Xerox Corporation in El Segundo, CA. 
Congratulations, Bruce! 


FaceSaver tm in Anaheim 

The USENIX FaceSaver Project made a 
smashing appearance at the Summer Confer¬ 
ence in Anaheim. It was set up in the vendor 
exhibit area, which gave us the room, power, 
and cooling we needed to run a comfortable 
operation. In three days of operation, we col¬ 
lected over 950 portraits, which have been sent 
to UUNET for on-line retrieval. These 
portraits have been added to, or replace the 
more than 3500 portraits already on file and 
are available via automatic mail request or via 
ftp. In addition to names and E-mail ad¬ 
dresses, these portraits may contain phone 
numbers, companies, and street addresses if 
supplied by the attendees. 

I want to thank the Association and its 
Board of Directors for sponsoring and funding 
this project. A very special vote of thanks 
goes to Stephen Freidl (KA8CMY) for lending 
us his amazing blazing laser printer. Thanks 
also to the QMS Corporation of Mobile, AL for 
providing a PS 820 laser printer, and to Bell 
Technologies (now a division of the Intel Cor¬ 
poration) for providing an 80386 system. We 
have been saving faces so often that FaceSaver 
is now a registered trademark of Metron Com- 
puterware. Ltd. of Oakland, CA. 

Craig Schwartz was our photographer 
again, assisted by Kathryn Johnson and Mark 
Hiltner. I am grateful to the tireless efforts of 
the smiling crew: Reidar Bomholdt, Petrus 
Hardianto, Ethan Ho, Spike (Joseph Ilacqua), 
Henry Mensch, Dave Rasmussen, and Brad 
Wong, who pounded away at the data termi¬ 
nals, dealt with the release forms and 
generated luggage tags hot off the press. 

Lou Katz, Saver of Lost Faces 

[For information on accessing the faces via 
uunet see page 20.] 
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Book Review 

UNIX System Administration 
Handbook 

Evi Nemeth, Garth Snyder, and 
Scott Seebass 

(Prentice-Hall, 1989, ISBN 0-13-933441-6) 

Reviewed by Nichlos H. Cuccia 

cuccia@Sybase.com 

UNIX system administration is a topic 
about which relatively little has been written, 
especially when compared to topics such as 
shell programming and document formatting. 
Much of what has been written until recently 
has been obsolete for many years, written with 
a decided slant towards AT&T’s System V, or 
focused on specific topics such as writing 
termcap or terminfo entries, or managing 
UUCP or netnews systems. While this may be 
adequate for a system administrator responsi¬ 
ble for a handful of machines running XENIX 
or System V, it ignores the needs of system 
administrators who have to manage networks 
of machines running BSD or BSD-based UNIX. 
It is into this gap that Evi Nemeth, Garth 
Snyder, and Scott Seebass leap with the UNIX 
System Administration Handbook. 

The Handbook is written at a level suit¬ 
able for begi nn i n g systems administrators. It 
covers a wide range of system and network 
administration issues, including: booting and 
shutting down systems; the use of superuser 
privileges; filesystem organization and file per¬ 
missions; monitoring and controlling 
processes; adding and deleting new users; 
adding terminals and devices, installing device 
drivers, and configuring system kernels; 
managing AT&T- and BSD-based printing 
systems; network hardware, software, and 
management issues; electronic mail, UUCP, 
netnews, and sendmail; backups and restora¬ 
tions; system daemons and processes spawned 
by cron; quotas and per-process limits; system 
security concerns; and issues such as file revi¬ 
sion control, local documentation, reporting 
bugs, and disk cleanup. Its seventeen appen¬ 
dices include C and csh source code for several 


useful utilities, in addition to a sample 
sendmail.cf file, a makefile used for saving and 
restoring system configuration files to or from 
tape, and forms for domain, IP address, and 
UUCP site registration. 

The Handbook is strongest when it 
discusses, in detail, topics that may mystify 
be ginning systems administrators. Sections of 
the book worthy of notice are: chapter two, 
which takes the reader through a sample 
/etc/rc file, as well as delineating strategies for 
dealing with systems that won’t boot, bad boot 
media, or corrupt filesystems; chapter fourteen, 
which discusses network issues ranging from 
the hardware required to set up a network and 
the configuration of system software to 
administrative issues including network 
security, licensing, and tools for monitoring 
and debugging network software and hardware; 
and chapter fifteen, which discusses sendmail 
in great detail. 

The Handbook does have its flaws, how¬ 
ever. There is a tendency to list online sources 
of information or source code as anonymous 
ftp repositories. This is reasonable for sites on 
the Internet, but the omission of anonymous 
uucp sites limits the ability of UUCP-only sites 
to acquire such software as the latest Berkeley 
sendmail or BIND. The omission of the semi¬ 
colon after the closing bracket of the tests in 
the sample /etc/rc file - an omission that does 
not occur in the snippets from an /etc/rc. local 
file in chapter fourteen - could have dire 
consequences for any user who tries to use it 
on a production system. These flaws, however, 
are not serious enough to diminish the useful¬ 
ness of the Handbook. 

In short, the UNIX System Administration 
Handbook is a must-have item for any user 
who wants to learn how to administer UNIX 
systems. Its occasional humorous touches, 
cute but informative drawings (especially the 
one that shows the difference between a bug 
and a feature), and its historical anecdotes 
(such as the origins of the name of the biff 
command) make it an interesting read. 
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Summary of Board of Directors’ Meeting 

Anaheim, CA, June 10 and 11,1990 


The regular quarterly meeting of the 
USENIX Board of Directors was convened in 
Anaheim, CA on June 10, 1990. 

Attendance: Steve Johnson, Rob Kolstad, Kirk 
McKusick, Sharon Murrel, Mike O’Dell, Alan 
Nemeth, John Quarterman, Deborah Scherrer, 
Ellie Young, Judy DesHamais, John Donnelly, 
Rick Adams, Eric Allman, Ed Gould, Lori 
Grab, John Mashey, Evi Nemeth, Sonya 
Neufer, Philip Peake, Barry Shein. 

Scherrer welcomed the newly elected 
directors. 

Workshop and Conference Status Report 

It was pointed out that Large Installation 
Sys Admin IV would once again offer a one 
day tutorial with two parallel tracks by Evi 
Nemeth and Rob Kolstad, and C++ was very 
successful and another one was planned for 
Spring of 1991. 

It was agreed to try and secure San Fran¬ 
cisco as a site for the Winter 1994 Conference. 

Anaheim Conference 

DesHamais reported that 1850 people had 
registered to date, and that this was a lot less 
than she had anticipated. Student interest was 
the highest ever with 140 registered. Mashey 
felt that the program committee needed a 
clearer report mechanism to give better feed¬ 
back to authors. The original review forms 
were inadequate. We should assign one person 
for every paper, where if the paper is not ac¬ 
cepted that person will provide written feed¬ 
back to the author. The Board formally 
thanked Mashey for his efforts in putting 
together an excellent program. 

Nashville ’91 

Scherrer said that the program would em¬ 
phasize music-related subjects and computer- 
generated music. It was suggested that we 
encourage people from multi-media worksta¬ 
tion product companies to make presentations. 


Executive Director’s Report 

It was decided that the speaker’s bureau 
and professional development seminar 
programs would be put “on hold” for the next 
six months. Nemeth pointed out that the 
membership of the committees was decided by 
the President. [See list appended to this 
report.] 

Budget 

The projected net income at the beginning 
of this meeting (including UUNET loan pay¬ 
ment and interest for this year) is $114,000. 
Most agreed that a survey would be a good 
method to gauge the membership’s interest in 
making the standards material into a separate 
publication. Young’s suggestion to mail ;login: 
via second class postage and proposal to in¬ 
crease student awareness of and involvement 
in the Association were approved. 

Proposal to Raise Conference Fees 

McKusick stated the reasons behind the 
proposal: that conference services have ex¬ 
panded over the past few years, and it appears 
that attendance is stabilizing. Since our margi¬ 
nal cost for D.C. was $110 per, it would be 
better to get registration fees to provide more 
of an income center. It was noted that the last 
time fees were raised was in 1987, and com¬ 
parison with other organizations showed that 
USENIX is well below others. After much 
discussion it was decided to raise the confer¬ 
ence registration fees beginning with the 
Winter 1991 conference from $150 to $195 for 
members and $235 for non-members. Student 
fees remain the same at $75 beginning with 
the Winter 1991 conference. 

UUNET Report 

Adams reported that a survey showed that 
80-90% subscriptions come from word of 
mouth. They are adding 65-100 sites per 
month. UUNET is looking into commercial 
areas (problem with nonprofit vs. profit traffic), 
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and he is waiting for an opinion from the State 
of Delaware. There were concerns that as 
UUNET gets more involved in commercial ac¬ 
tivities and in forming a separate for-profit 
corporation, this could have an impact on 
USENIX. Young was instructed to get advice 
from our attorney, and Adams would provide 
a written statement of the proposed change. 

Journal Report 

O’Dell said that the first issue for 1990 
was finally at the printer, and the second 
(music) would follow shortly. He and Salus 
hoped to be back on schedule by the Fall. 

Scholarships 

Scherrer reported that there were ten can¬ 
didates, and that two graduate students had 
been selected: John Heidermann of UCLA and 
Matthew Blaze at Princeton as runner-up. The 
committee would work on recommending an 
evaluation criteria and a proposal for an addi¬ 
tional scholarship. 

EUUG Report 

Philip Peake reported that they had 
recently added Czechoslova ki a and Yugoslavia 
as members. At their last meeting there had 
been a discussion about changing their name 
to remove the words “UNIX” and 
“European.” EUUG was also planning to set 
up their own standards working groups. 
Nemeth felt that everything that Peake had 
reported on is negative: 1) change in name 
will cause change in interpretation, and other 
groups (USENIX, JUS, etc.) will appear to be 
subservient; 2) another standards hierarchy 
will be a waste of energy; 3) change to remove 
UNIX word is okay and he hopes we maintain 
a good relationship with the new group as we 
have in the past with EUUG. 

Standards Liaison Report 

Quarterman summarized his report. At 
the IEEE 1003 meeting in April they were suc¬ 
cessful in slowing down the rate of new PARs 
by developing a set of PAR approval criteria. 
At the next meeting ways to define and apply 
criteria for dissolving groups that are either 
inactive or have inadequate representation 
would be discussed. He also reported that he 
had received only one response (from AUUG) 


to the invitation letter regarding an interna¬ 
tional standards group. 

South Africa Question 

Scherrer outlined the following: 

1. University of Capetown has requested 
membership. 

2. Legality of their becoming a member is 
unknown. 

3. We can request a determination as to their 
status as an apartheid-enforcing agency. 

4. Membership is open, but we are allowed 
to deny an application. Our attorney’s in¬ 
terpretation of the bylaws is that to deny 
membership we should have a statement on 
file or an explicit action in the minutes as to 
why we are denying membership. 

After a long discussion, it was moved by 
Johnson, seconded by Kolstad that the 
membership application of the University of 
Capetown be rejected on the grounds that the 
Board doesn’t wish to spend its energy and 
resources on pursuing a determination of 
whether that University is an exception to the 
U.S. embargo of South Africa. Passed: 6 in 
favor; 1 opposed (Quarterman); 1 abstained 
(Nemeth). Quarterman explained that he 
voted negatively because the legal proof will 
come back from the University of Capetown. 
Nemeth’s reasons for abstaining is his concern 
for the precedent that we set, and there still 
exists a fundamental political component in 
the question. 

Other Business 

Scherrer commented that she thought the 
electorate did a good job, and wished the new 
directors good luck. McKusick remarked that 
there was 25 years of collective service with 
the four outgoing board members, and ex¬ 
pressed his thanks for all they have done. 

Next Board Meeting 

The next board meeting will be held in 
Berkeley, California, beginning Monday, Sep¬ 
tember 24. 

-EY 
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USENIX Committees 

New Conference Sessions: Lori Grab, 

Eric Allman, Andrew Hume, Sharon Murrel. 

Executive: McKusick, Kolstad, Gould, Murrel. 

Online: Scherrer. 

Prof. Development Seminars & Speaker’s 
Bureau: Kolstad. 

Publications: O’Dell (Chair), Johnson, Murrel, 
Donner. 


Scholarship: Shein, Kolstad. 

Standards Liaison Funding: McKusick, 

A. Nemeth. 

Standards Policy: Quarterman, A. Nemeth, 
McKusick. 

Tutorial Review: Gould, Wedel, Taylor. 

University Outreach: Kolstad, E. Nemeth, 
Dan Geer, Sonya Neufer, Dan Klein. 

* Young is on all above committees. 


Board of Directors’ Long Range Planning Session Report 

Berkeley, CA, April 5,1990 


Attendance: 

Board of Directors: Steve Johnson, Rob 
Kolstad, Kirk McKusick, Sharon Murrel, 
Michael O’Dell, Alan Nemeth, John 
Quarterman, and Deborah Scherrer, 

Executive Director: Ellie Young 

Nominees: Rick Adams, Peter Collinson, 
Daniel Geer, Ed Gould, Daniel Klein, Evi 
Nemeth, Sonya Neufer, Barry Shein, Dave 
Taylor, and Max Vasilatos. 

Whither USENIX - Facilitator: Steve Johnson 

Topic: Where do we go now that UNIX has 
matured? Can we clearly define our purview? 
What do we have to offer that makes us unique, 
viable in 5 years? What is our role in relation 
to UNIX and to other operating systems? Is 
there a difference between a user group and a 
technical professional society? If so, how do we 
make clear the distinction and how does this 
relate to services, to evaluating projects, and 
especially to what we address in our conferences 
and workshops? 

Johnson said that he envisioned this session as 
focusing on where the technology is going and 
who are the individuals involved. He felt that 
UNIX in 3-5 years will be boring. A. Nemeth 
said that systems with lots of processors cou¬ 
pled together with your favorite architectural 


schema will be preferred in the years to come, 
and it is important that we get involved in this 
problem. Gould felt that the USENIX 
membership is changing and becoming bimo- 
dal (not just end-applications users, but users 
of system programs). 

A. Nemeth felt that an important role for the 
Board is to make tactical calls regarding 
workshop topics, and to keep informed about 
our changing audience. 

Geer said that the Association should have as 
its technical goal the ideal of “location in¬ 
dependent cooperative work.” Such a goal na¬ 
turally encompasses open systems, and com¬ 
puting as a commodity/utility on a par with 
heat, power, and light. UNIX is not an end 
unto itself, but the clearest path to the real 
goal(s). Others felt that this is not our charter. 
Nemeth said that USENIX is unique with its 
practical view of technology. Geer felt that the 
organization filters information. 

Johnson inquired as to who our membership 
might be in 3-5 years? O’Dell felt that they 
are the systems engineering community as well 
as those interested in fixing things. Geer said 
that it is the Association’s job to accelerate 
evolution of our computing environment by 
providing exposure to good ideas and filtration 
of poorer ones, political support for open 
systems, and the distribution of reference im¬ 
plementations. 
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Nemeth asked the group for feedback as to 
how close we are to the Association’s 
goals/statement. 

Statement: The USENIX Association is a not- 
for-profit organization of those interested in 
UNIX and UNIX-like systems. It is dedicated to 
fostering and communicating the development 
of research and technological information and 
ideas pertaining to advanced computing 
systems, to the monitoring and encouragement 
of continuing innovation in advanced comput¬ 
ing environments, and to the provision of a 
forum where technical issues are aired and crit¬ 
ical thought exercised so that its members can 
remain current and vital. 

A. Nemeth felt there is a problem in that we 
have not dealt with the coming round of a 
large number of people that are users of UNIX 
systems, and how do we deal with them? 

Neufer. Users concerns are not addressed. 

Taylor. Our goal should be to make UNIX a 
more productive environment. 

Kolstad: USENIX is a facilitator and promoter 
of information transfer, and we do a good job. 

O’Dell: We need to address system engineers’ 
concerns. 

Collinson: USENIX is the “village party.” The 
momentum is not slacking off, so we don’t 
have a problem. 

Geer. We are driven by big goals and should 
make sure computing becomes freely available. 

Adams: There is too much complacency. 

E. Nemeth: Should emphasize USENIX as a 
forum for testing new technology, and support 
new non-guru technology. 

McKusickr. He would like a discussion on fine 
tuning what we are doing now, and for the 
present has no new goals. 

Young 1 . We need to continue to stay in touch 
with changing interest areas and be proactive 
in finding new topics (e.g., workshops). 

Klein: Need to be more proactive. 

Murrel: Wants a better definition of the audi¬ 
ence we want to speak to. 


Gould: Kemel/guru types concerns are ad¬ 
dressed, and we need to address other interest 
areas. 

Quarterman: Feels the same as Gould, and we 
need to continue to have new people involved. 

Johnson summarized that he hoped the discus¬ 
sion would provide “macros” such as “village 
party” that we could use to shortcut discussion 
in future board meetings. 

External Relations - Facilitator: Barry Shein 

Topic: The issue at hand was what external re¬ 
lationships should USENIX develop with other, 
similar groups, and how do we decide whether 
another group has interests similar to ours? 

The goal of this discussion was to outline the 
forms these external relationships might take, 
make a list, and continue the discussion at a 
later date. Towards that end, the following list 
of possible areas of joint activity between 
USENIX and other groups was outlined by 
everyone present, for further consideration: 

1. Joint workshops. 

2. Joint publications and books. 

3. Joint educational campaigns. 

4. Sharing speakers for various events. 

5. Coordinating conferences. 

6. Interlocking Boards of Directors. 

7. Promote greater University cooperation. 

a) Student Chapters of various organiza¬ 
tions. 

b) Student Papers. 

8. Internet and on-line publications. 

9. Cooperation with computer societies and 
outreach to not-so-obvious groups such as the 
Human Genome Project. 

10. Joint interchange of publications. 

11. Eastern European User groups if similar 
interest should be sought out, the same can be 
said world-wide. 

12. Formation of umbrella groups for specific 
goals such as professional insurance. 
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13. Liaison with government organizations, 
NIST, OTA, etc. 

14. Inviting other groups’ papers for possible 
re-presentation at our conferences. 

15. Dissertations, putting indices on-line. 

16. Suggest to Program Chairs of conference 
that we include sessions on “outside topics,’’ 
e.g., “The Grand Computational Challenge.” 

17. Unilaterally sending .login to board 
members of other user groups. 

18. Industry liaisons. 

19. Getting the non-computer industry on-line 
as a goal, outreach to non-computer industry 
groups. 

Outreach/Public Relations - 
Facilitator: Rob Kolstad 

Topic: The Association’s formal public rela¬ 
tions and publicity activities have, in the past 
few years, been almost exclusively targeted to 
the press. Is this the right focus and, if not, 
what other mechanisms can we use to 
appropriately channel our efforts and funds to 
the right audience? Specifically: 

9 How do people learn about USENIX, and 
should we exert more effort to disseminate in¬ 
formation about USENIX? 

• Should we attempt more in-depth penetra¬ 
tion of universities, even with our “pragmatic 
orientation?” 

• Do we want or need more members? How 
do we deal with members of various back¬ 
grounds (and succeed for all of them)? Do we 
wish "open membership” or should there be 
some kind of qualification criteria? 

All agreed that we cannot and should not limit 
the membership. We need to be specific about 
defining ourselves as technical, and this will 
determine and limit membership. We should 
continue to encourage new people to join 
USENIX, and the extra conference tracks along 
with our statement is a good way to proceed. 

It was agreed that we could not limit atten¬ 
dance at conferences, but that we do in fact 
because of what we offer. 


How do we get more of the university com¬ 
munity involved? Suggestions included: 

• Programming contest 

• Undergraduate scholarship 

• Student chapters (e.g., ACM) 

• Target the professors 

• Target students through mailings and elec¬ 
tronic bulletin boards 

Kolstad summarized the notion that USENIX 
needs to penetrate academia in a more organ¬ 
ized way, and a committee was formed to 
meet in Anaheim (Klein, Geer, Neufer, 
Kolstad and Evi Nemeth). 

It was also suggested that USENIX contact 
members of local universities to participate in 
and potentially render assistance at the various 
conference venues. 

In summary, USENIX: 

• should not explicitly limit its membership 
and conference attendance 

• should not explicitly narrow its focus 
more than the charter implies 

o will continue to offer high quality, innova¬ 
tive tutorials 

• will continue to find ways to involve the 
university community 

Standards - Facilitator: Alan Nemeth 

The Board and nominees discussed the role of 
USENIX in the standards community. Stan¬ 
dardization of the components of the UNIX 
operating system (excuse me, open systems en¬ 
vironment) is a very active area at this point, 
and USENIX has held only a limited role. The 
questions we debated were the nature of our 
role and its interaction with other activities of 
the Association, and possible changes in the 
role. 

In order to understand the discussion, it is 
best to put some framework around the stan¬ 
dards activities. Open systems standards are 
driven by a rather different industry dynamic 
than previous standards work. The goal of 
every major computer vendor worldwide is to 
offer a competitive product line incorporating 


18 


July/August 1990 



;login: 15:4 


a standards-compliant operating system com¬ 
ponent. The operating system component is a 
complicated entity for standardization, and the 
problem is compounded by variations in exist¬ 
ing practice among the vendors. Representa¬ 
tives of large purchasers (especially such 
governmental entities as the National Institute 
for Science and Technology (NIST) and the 
European Commission) are actively encourag¬ 
ing the standards activity to proceed quickly 
so that multiple suppliers can satisfy purchase 
requirements. 

IEEE began the POSIX activity to satisfy the 
emerging need for a standard describing the 
areas of the operating system where agreement 
existed amongst the vendors and purchasers. 
The IEEE PI003 committee (in the initial 
stages, that was a unique enough description) 
started from several existing documents pur¬ 
porting to describe the same interface, and in 
relatively short order (for standards groups; 
but not in relation to the desired rate of 
market development) produced a full-use stan¬ 
dard describing the base operating system 
component interface. In the course of this 
work, a large number of related areas 
necessary to provide a complete environment 
were also identified. The pressure to support a 
unified environment was large, both from ven¬ 
dors and purchasers. As a result, the POSIX 
work extended to its current status of over a 
dozen subcommittees, with new subcom¬ 
mittees started at almost every meeting. In 
addition, a joint International Standards Or¬ 
ganization and International Electrotechnical 
Commission Working Group (ISO/IEC JTC1 
SC22 WG15), sometimes known as the ISO 
POSIX Committee, began work on adoption of 
standards at an international level - in many 
cases, based on work of the IEEE group. 

USENIX, at the beginning of the standardiza¬ 
tion activity, generally stayed away from these 
efforts as an organization, although many in¬ 
dividual USENIX members have been active 
from the earliest stages. The Board attitude 
was that our role was to provide a platform for 
discussion of new, developing technologies, 
and that others would drive the need for sta¬ 
bilization of the technology. As the magnitude 
of the effort became clearer, we realized that it 


was important to participate to achieve some 
limited goals: 

1. To attempt to prevent standards from 
prohibiting innovation, and 

2. To communicate to our members key 
decisions taken within the standards groups, 
and to add some perspective on the technical 
implications of these decisions. 

These items have been the essence of our stan¬ 
dards policy for approximately the past five 
years. During this time, the scale of activity in 
the standards community has increased 
dramatically and our work has expanded as 
well. USENIX provided an Institutional 
Representative to POSIX in the early days of 
PI003, and used this official role to identify 
areas causing potential problems. We have 
also encouraged research groups (most particu¬ 
larly, the Berkeley group) to participate ac¬ 
tively in some key decision areas in the stan¬ 
dards arena. 

With the recent broadening of standards ac¬ 
tivity, the widening adoption of the X/Open 
Portability Guide and the advent of the Open 
Software Foundation and UNIX International 
as technology providers in the marketplace, it 
has become even more crucial that USENIX 
continue to reiterate the need for a technically 
satisfactory standard without the constraints 
inherent in vendor representatives. We have 
recently begun joint sponsorship with EUUG 
(European UNIX Users Group) of a represen¬ 
tative to the WG15 activities. In addition to 
the group of volunteers who write reports on 
the activities of the standards committees, we 
now have a paid report editor and a part time 
paid staff member to coordinate USENIX stan¬ 
dards activities. 

One particular issue of recent concern is the 
possibility of joining with other UNIX-related 
groups (such as EUUG, AUUG - Australian 
UNIX User Group, and JUS - Japanese UNIX 
Society) to co-sponsor activity at the ISO level 
where representation as a national group 
would be inappropriate. A proposal is 
currently circulating for comment describing 
how such an arrangement might work, with 
the focus primarily on information dissemina¬ 
tion. 
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Overall, we reaffirmed this general direction in 
the long-range planning session. We are reluc¬ 
tant to dramatically expand our standards 
work, but also, we bring to the standards 
bodies a viewpoint different than others, and 
necessary to assure standards with long life. 


1990-91 USENIX Scholarship Winners 

Because of the excellence of the applicants 
this year, the USENIX Association will award 
two scholarships for 1990-91. The winner of 
the competition is John Heidemann, UCLA. 
The runner-up award has been given to 
Mathew Blaze, Princeton. 


Information on Accessing the Faces via uunet 


Welcome to faceserver, a system for distribu¬ 
tion of faces by electronic mail and other 
means. This index is the reply you’ll get to: 

echo help I mail uunet!faceserver 

Be sure to escape the exclamation point if you 
are using the C shell. 

To examine the full index for all the faces 
send a request of the form: 

echo send full-index I mail uunetIfacei 

You may include several requests in a single 
piece of mail, but put each on a separate line. 

Faces are usually stored by their electronic 
mail address (e.g., rick@uunet.uu.net would be 
stored as uunet.uu.net/rick). So, to get Rick’s 
face, you would send the command: 

send uunet.uu.net/rick 

uucp sites’ names are stored in a domain-ish 
format (e.g., usenixllou would be stored as 
usenix.uucp/lou). So, to get Lou’s face, you 
would send the command: 

send usenix.uucp/lou 


Those faces that do not have an email address 
associated with them are stored in the direc¬ 
tory no-email-address by their first Jastname, 
e.g., 

send no-email-address/p_s_langston 
(see the full-index for the actual names). 

The format of the files is described in the 
file format. To get it, 

send format 

To request programs, send the command: 

send index from programs 
To get a specific program, 

send WHATEVER from programs 

Send the requests to uunetlfaceserver even 
though replies appear to be coming from 
uunet!faceserverd. You’ll be talking to a 
program, so don’t expect it to understand 
much English. 

Remember, of course, if you have access 
to ftp, the faces are stored on uunet.uu.net. 
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An Update on UNIX and C Standards Activity 

May and June, 1990 

Jeffrey S. Haemer 

Report Editor, USENIX Standards Watchdog Committee 


Report on USENIX Standards 
Watchdog Committee 

Jeffrey S. Haemer <jsh@ico.isc.com> reports 
on spring quarter standards activities: 

What these reports are about 

Reports are done quarterly, for the USENIX 
Association, by volunteers from the individual 
standards committees. The volunteers are 
familiarly known as snitches and the reports as 
snitch reports. The band of snitches and I 
make up the working committee of the 
USENIX Standards Watchdog Committee. 
Our job is to let you know,about things going 
on in the standards arena that might affect 
your professional life - either now or down the 
road a ways. 

We don’t yet have active snitches for all 
the committees and sometimes have to beat 
the bushes for new snitches when old ones 
retire or can’t make a meeting, but the number 
of groups with active snitches continues to 
grow (as, unfortunately, does the number of 
groups). 

We know we currently need snitches in 
1003.6 (Security), 1003.11 (Transaction Pro¬ 
cessing), 1003.13 (Real-time Profile), and 
nearly all of the 1200-series POSIX groups, 
There are probably X3 groups the USENIX 
members would like to know about that we 
don’t even know to look for watchdogs in. If 
you’re active in any other standards-related ac¬ 
tivity that you think you’d like to report on, 
please drop me a line. Andrew Hume’s fine 
report on X3B11.1 is an example of the kind 
of submission I’d love to see. 

If you have comments or suggestions, or 
are interested in snitching for any group, 
please contact me (jsh@usenix.org) or John 
(jsq@usenix.org). If some of the reports make 
you interested enough or indignant enough to 
want to go to a POSIX meeting, or you just 


want to talk to me in person, join me at the 
next set, July 16-20, at the Sheraton Tara, in 
Danvers, Massachusetts, just outside of Bos¬ 
ton. 

The USENIX Standards Watchdog Com¬ 
mittee also has both a financial committee - 
Ellie Young, Alan G. Nemeth, and Kirk 
McKusick (chair); and a policy committee - 
the financial committee plus John S. Quarter- 
man (chair). 

An official statement from John S. Quar- 
terman, USENIX Standards Liaison: 

The basic USENIX policy regarding standards is: 

to attempt to prevent standards 
from prohibiting innovation. 

To do that, we 

• Collect and publish contextual and technical 
information such as the snitch reports that other¬ 
wise would be lost in committee minutes or ra¬ 
tionale appendices or would not be written down at 
all. 

• Encourage appropriate people to get involved 
in the standards process. 

• Hold forums such as Birds of a Feather (BOF) 
meetings at conferences. We sponsored one 
workshop on standards, and are cosponsoring 
another in conjunction with IEEE, UniForum, and 
EUUG. (Co-chairs are Shane P. McCarron, 
ahby@uiunix.org, and Fritz Schulz, 
fritz@osf.osf.org. Contact them for details.) 

• Write and present proposals to standards 
bodies in specific areas. 

• Occasionally sponsor White Papers in particu¬ 
larly problematical areas, such as IEEE 1003.7 (in 
1989). 

• Very occasionally lobby organizations that 
oversee standards bodies regarding new committees, 
documents, or balloting procedures. 

• Starting in mid-1989, USENIX and EUUG (the 
European UNIX systems Users Group) began 
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sponsoring a joint representative to the ISO/IEC 
JTC1 SC22 WG15 (ISO POSIX) standards committee. 

There are some things we do not do: 

• Form standards committees. It’s the USENIX 
Standards Watchdog Committee, not the POSIX 
Watchdog Committee, not part of POSIX, and not 
limited to POSIX. 

• Promote standards. 

• Endorse standards. 

Occasionally we may ask snitches to present 
proposals or argue positions on behalf of USENIX. 
They are not required to do so and cannot do so 
unless asked by the USENIX Standards Watchdog 
Policy Committee. 

Snitches mostly report. We also encourage 
them to recommend actions for USENIX to take. 


Report on IEEE 1003.0: POSIX Guide 

Kevin Lewis <klewis@gucci.dco.dec.com> 
reports on the April 23-27 meeting in Salt 
Lake City, UT: 

Where we are 

The Utah meeting of the IEEE 1003.0 working 
group marks the beginning of its third year. 
Let’s step back for a moment to review the 
past two. We have gone from scratch to a 
180-page document, the content of which 
represents about 70% of the content goal that 
we set for our work two years ago. (More on 
this in a moment.) 

This effort represents the contributions of 
a core group of 15 to 18 people. In 1988, 14 
vendor organizations and 16 user organiza¬ 
tions were represented within the group. To¬ 
day, we have nine vendor organizations and 
16 user organizations represented. Of course, 
the only official formal organizational 
representatives allowed within IEEE working 
groups are accredited institutional representa¬ 
tives (currently Usenix, UniForum, X/Open, 
Unix International, and the Open Software 
Foundation each supply one to the POSIX 
effort), but that does not stop me from check¬ 
ing the sign-up sheet whenever a new face 
shows up, to see where he or she works. For 
example, I think someone from the Univ. of 


Berkeley involved in BSD UNIX development 
has a vendor’s perspective, while I place atten¬ 
dees from NIST and the Air Force in the user 
category because I believe they focus on the in¬ 
terests of their own end users. Our stable 
steady user representation is essential: our ulti¬ 
mate targets are users trying to walk through 
the POSIX maze. 

The 70% completion of our initial content 
goal includes the introduction of the “profile” 
concept, which has led to increased activity 
within the IEEE TCOS Standards Subcom¬ 
mittee to create groups to define profiles 
(which may be good or bad depending on your 
own prism). The concept of profiles is also 
part of the US’s contribution to the ISO com¬ 
munity, made through its participation in the 
JTC1 Technical Study Group on Application 
Portability (JTAP), within which the “profiles” 
concept has now garnered wide acceptance. 

“What is a profile?” you ask. Users seek¬ 
ing open system solutions need to know what 
parts of the open system environment (OSE) 
address their requirements. If a user could 
reach into the full basket of OSE parts and pull 
out only those he or she specifically needs, 
those selected parts would be his or her appli¬ 
cation environment profile. What should the 
user do if he or she needs something not in the 
basket? Come to our next meeting with a 
recommendation. [Editor: Or drop Kevin a 
line, or post something to comp.std.unix!] 

Where we’re going 

Dot Zero still faces hard decisions in two 
areas: 

1. the necessity or desirability of parts of our 
guide. (Two parts that I very much think are 
candidates for this discussion are User Inter¬ 
face and Security.) 

2. The final bounds of the profile 
concept/definition. 

The group’s arguments in these areas are 
not frivolous, but if they continue much 
longer, the resulting lack of movement will 
hurt our overall effort. 

I came out of this meeting feeling that 
everyone is committed to getting over these 
hurdles soon (i.e., by the July meeting). Our 
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chair, A1 Hankinson, has also stated that we 
should target December 1990 for a mock bal¬ 
lot. I wholeheartedly agree. This will add the 
impetus that we need. Let’s see if we have the 
self-discipline to get there. 

Report on IEEE 1003.1: 

System services interface 

Paul Rabin <rabin@osf.org> reports on the 
April 23-27 meeting in Salt Lake City, UT: 

Introduction 

The POSIX 1003.1 working group is the oldest 
POSIX group, responsible for specifying 
general-purpose operating system interfaces for 
portable applications. This group developed 
the original 1988 POSIX standard, and is now 
responsible for writing supplements and revi¬ 
sions to that standard. This work includes 

• corrections and clarifications to the 1988 
POSIX standard 

• material that was too controversial to han¬ 
dle before 

• new interfaces requested by other POSIX 
working groups 

Like other working groups developing 
“base standards,” the 1003.1 working group is 
responsible for writing both C language and 
language-independent versions of the 
specifications that it develops. So far, the 
group has concentrated on the C language ver¬ 
sions, but there is increasing pressure to make 
progress on the language-independent 
specifications. 

The working group recently completed a 
revision of the 1988 POSIX standard, and is 
currently working on a supplement to that 
revision. 

There has been a lot of turnover in the 
group since the 1988 POSIX standard was 
completed, but there are still a few old-timers 
to provide continuity. About 15 people at¬ 
tended the last two meetings. This seems to 
be a good size for getting work done. This is 
definitely a technical crowd; check your poli¬ 
tics at the door. 


For more information about the group 
and how to participate, contact the chair, 
Donn Terry, at donn@hpfcla.fc.hp.com or 
hplabs!hpfcla!donn. Send comments and 
proposals to the secretary, Keith Stuck, at 
keith@sp7040.uucp. I’ve made this report a 
bit more detailed than usual in order to give 
the technical details wider exposure. New 
proposals and comments on any of the current 
active proposals or issues are welcome. 

1003.1a Status 

1003.1a is the recently completed revision to 
the 1988 POSIX standard. No new interfaces 
or features were introduced, but the text was 
revised in several ways. The main reason for 
the revision was to prepare the text for ballot¬ 
ing as an ISO standard, so the document had 
to be made to look like an ISO standard. This 
meant adding ISO boiler-plate, changing exter¬ 
nal document references to pretend that only 
standards exist, changing internal cross- 
references so that chapters are renamed sec¬ 
tions, and sections are renamed clauses and 
subclauses, changing “will” to “shall,” etc., ad 
nauseam. While the working group was hav¬ 
ing fun with all that, they took the opportunity 
to do some cleaning up. They corrected 
errors, clarified unclear language, and changed 
the function synopses to use ANSI C proto¬ 
types. The group did make one normative 
change, which was to specify reserved 
namespaces. This will allow implementations 
and revisions to the standard to define exten¬ 
sions without breaking existing conforming ap¬ 
plications. It’s messier than you might think. 

After four recirculation ballots, IEEE bal¬ 
loting was completed in April. Now it has to 
get through the ISO balloting process. See the 
recent snitch report on 1003.5 for a descrip¬ 
tion of how IEEE and ISO balloting is syn¬ 
chronized, and what all of the acronyms mean. 

ISO has been balloting 1003.1a as ISO/IEC 
DIS 9945-1. After the first ISO ballot, JTC1 
approved 9945-1 for promotion to full IS 
status. This approval was overruled by the 
ISO Central Secretariat on the grounds that the 
document format was still not satisfactory (still 
haven’t caught all of those “will”s). Rather 
than publish the current document and then 
immediately revise, ballot, and publish it 


July/August 1990 


23 



;login: 15:4 


again, it was decided to create a new DIS and 
to start a second round of ISO balloting. This 
will cause a delay in the publication of the 
international POSIX standard (and hence also 
the IEEE POSIX. 1 standard). The U.S. Techni¬ 
cal Advisory Group (TAG) is responsible for 
generating the U.S. ballot. Assuming that no 
normative changes are introduced by the ISO 
balloting process, the resulting document will 
be published by IEEE as IEEE Std 1003.1-1990. 

1003.1b Status 

Since 1003.1a is now out of IEEE’s hands, the 
working group spent the Utah meeting working 
on 1003.1b, the first supplement to 1003.1a. 
This will include some corrections and 
clarifications that didn’t make it into 1003.1a, 
but will mainly consist of new interfaces and 
features. 

1003.1b has been in the works for several 
meetings, so the draft already contains a lot of 
material. The first day was devoted to revi¬ 
sion of the draft, the rest of the week to con¬ 
sidering new proposals. The previously an¬ 
nounced schedule for 1003.1b specified the 
Utah meeting as the cutoff date for new 
proposals. Unfortunately, some expected 
proposals were not received, and some that 
were received were not ready for incorpora¬ 
tion, so the cutoff was deferred until the next 
meeting, in Danvers, Massachusetts. 

Draft 2 of 1003.1b was distributed just be¬ 
fore the meeting in Utah. Draft 3 should be 
available before the Danvers meeting. 1003.1b 
is expected to be approved sometime in early 
1991, and to be published by IEEE as a 
separate supplement to the IEEE Std 1003.1- 
1990. 

New Features in the Current Draft of 1003.1b: 
Draft 2 of P1003.1b includes a new data inter¬ 
change format, and new interface 
specifications for symbolic links, environment 
list access, and file-tree walking. These had 
been proposed and generally accepted at previ¬ 
ous meetings. Many new issues were raised 
and discussed. 

Symbolic Links: PI003.lb adds BSD symbolic 
links to the 1988 POSIX standard as a new re¬ 
quired feature. New interfaces for symlink(), 
readlink(), and IstatQ are specified, and the 


definition of pathname resolution is amended 
to include the handling of symbolic links. Im¬ 
plementations may optionally enforce a limit 
on the number of symbolic links that can be 
tolerated during the resolution of a single path¬ 
name, for instance to detect loops. The new 
symbol { _POSIX_SYMLOOP ) is defined to be 
the minimum value of such a limit. A new 
error, [ELOOPJ, is returned if such a limit is 
exceeded. Symbolic links that are encountered 
in pathname prefixes are always resolved. 
Symbolic links named by the final component 
of a pathname will be resolved or not, depend¬ 
ing on the particular interface. By default, 
such symbolic links will be resolved, unless 
specified otherwise. The interfaces that will 
not resolve symbolic links named by pathname 
arguments are: 

readlink() If the pathname argument names a 
symbolic link, the contents of the link will be 
returned. 

IstatQ If the pathname argument names a 
symbolic link, a stat structure will be returned 
for the link itself. 

unlinkQ If the pathname argument names a 
symbolic link, the link itself will be removed. 

rmdirQ If the pathname argument names a 
symbolic link, the link will not be followed 
and the call will fail. 

openQ Symbolic links are followed, unless 
both 0_CREAT and 0_EXCL are set. If both 
0_CREAT and 0_EXCL are set, and the path¬ 
name argument names an existing symbolic 
link, the link will not be followed and the call 
will fail. 

linkQ If the new pathname names a symbolic 
link, the link will not be followed and the call 
will fail. If the old pathname names a sym¬ 
bolic link, the link will be followed. This is 
the BSD behavior. SVR4.0 does not follow the 
link in this case, thus supporting hard links to 
symbolic links. The working group felt that 
the SVR4 behavior unnecessarily restricts im¬ 
plementations (for instance, those that do not 
implement symbolic links with inodes), and 
has much more complex semantics. 

renameQ If the old pathname names a sym¬ 
bolic link, the link will not be followed. In¬ 
stead, the symbolic link itself will be renamed. 
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If the new pathname names a symbolic link, it 
will not be followed. Instead, the symbolic 
link will be removed, and a new hard link will 
be created naming the file that was previously 
named by the old pathname. 

The 1988 POSIX standard specifies that if the 
new pathname names an existing file, renamef) 
will fail if the new and old pathnames do not 
either both name directories or both name 
non-directory files. This rule needs to be ex¬ 
panded to include the case of the new path¬ 
name naming a symbolic link. Should the 
renamef) call fail depending on whether or not 
the symbolic link named by the new pathname 
itself names a directory or a non-directory file? 
This will be resolved at the next meeting. 

Symbolic links are not required to have 
any attributes other than their file type and 
their contents. This is intended to provide the 
simplest semantics and to allow the greatest 
latitude for implementations. 

Other BSD Interfaces : P1003.1b also includes 
specifications for the following interfaces: 

fchmod() 

fchownQ 

fsync() 

ftruncateQ 

Environment List. The ANSI-C standard 
defines the getenvQ function to retrieve the 
value corresponding to a given name in a 
program’s environment list, but does not 
specify the implementation or initialization of 
that list. The 1988 POSIX standard specified 
the traditional list implementation using the 
external variable environ, and specified the ini¬ 
tialization of the list by the exec functions. In 
an attempt to extend the set of high-level in¬ 
terfaces to the environment list, and to pave 
the way for the possible eventual removal of 
environ, the working group has included 
putenvQ and clearenvQ interfaces in 1003.1b. 
Three problems have been identified with 
these high-level interfaces: 

1. They cause static data to be shared 
between the application and the implementa¬ 
tion. Neither the application nor the imple¬ 
mentation can easily manage the storage for 
environment " name=value " strings. 


2. They are not robust. The interactions 
between the high-level interfaces and access 
via environ are not specified. 

3. They can’t be easily extended to handle 
multiple lists. There is no way to copy a list, 
or to build a new list for execle() or execveQ. 

The putenvQ and clearenv() interfaces may 
be removed from 1003.1b at the next meeting 
if a revised proposal does not appear. 

File Tree Walk. The 1003.1 working group 
promised the 1003.2 group (Shell and Utilities) 
that a mechanism would be provided for walk¬ 
ing a directory tree of unbounded depth using 
any given (non-zero) number of free file 
descriptors. The Berkeley folks have imple¬ 
mented a set of high-level interfaces defined by 
David Korn of Bell Labs, and proposed them 
for inclusion in 1003.1b. These interfaces sup¬ 
port every option and search order required by 
the 1003.2 commands. The 1003.1 group 
wants a simpler interface suitable for typical 
application programs, so Keith Bostic will put 
the proposal on a “weight-reducing diet” and 
resubmit it for the next draft. 

The high-level file-tree walk interfaces can 
be implemented using only the existing 1003.1 
interfaces. Since 1003.1 does not define a 
portable way to save and restore file position 
for a directory and cannot hold a file descrip¬ 
tor open for each directory level, the imple¬ 
mentation must read and save all directory en¬ 
tries each time a new directory is visited. This 
requires only a single file descriptor (or what¬ 
ever resource is used by by opendirQ). If the 
underlying system does provide a way to save 
and restore file position for directories, the 
file-tree walk implementation can use it to 
reduce memory consumption. 

There was a discussion about whether it is 
possible (and preferable) to improve the low- 
level directory interfaces instead of adding new 
high-level interfaces. Do the high-level inter¬ 
faces really add new functionality for portable 
applications? Do they belong with the low- 
level operating system interfaces specified in 
1003.1? 

Walking an unbounded file tree requires 
an unbounded number of directory file posi¬ 
tions to be supported using a bounded number 
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of file descriptors. Either seekdirQ and telldirQ 
are needed, or an unbounded number of 
opendir() s must use a bounded number of file 
descriptors. The working group has already re¬ 
jected seekdir() and telldir() because they can¬ 
not easily be supported on implementations 
that use a non-linear directory format. A 
prohibition of simple implementations of 
opendir() using file descriptors is also likely to 
be rejected. 

The underlying problem is that the 
orderedness of directory entries was implicit in 
the traditional implementations, but was not 
made fully explicit in 1003.1, partly out of a 
desire to permit alternate implementations (for 
instance, b-trees). As a result, orderedness 
must now be imposed by the application. On 
a non-linear directory implementation, if posi¬ 
tioning is not supported, even opendir() must 
read in the whole directory. 

Data-Interchange Format : The 1988 POSIX 
standard specified two data-interchange for¬ 
mats based on existing utilities. These define 
the data-stream encoding of a sequence of files, 
together with their pathnames and other attri¬ 
butes. The first format is based on tar and 
encodes files as a stream of 512-byte blocks. 
The second format is based on cpio and 
encodes files as an unblocked byte stream. 

The ISO POSIX group (JTC1/SC22/WG15) 
pointed out that both of these formats are in¬ 
compatible with accepted international and 
U.S. standards. After some arm twisting, the 
1003.1 working group agreed to devise a new 
data interchange format based on IS 1001: 
1986, which is more or less equivalent to ANS 
X3.27-1987, the familiar ANSI labeled tape 
format. 

The current draft of 1003.1b includes the 
framework for the new specification, but a lot 
more work is needed. Previous meetings 
discussed alternate proposals. The topic has 
been strangely quiet lately, considering the 
confusion that may be expected when it goes 
to ballot. It wasn’t discussed at the Utah 
meeting at all. 

{_POSLX_PATH_MAX}: A Clarification: The 
1988 POSIX standard included two conflicting 
statements regarding { _POSIX_PA TH_MAX] 
and { PATH_MAX): one said that the null was 


included in the count; the other said that the 
null was excluded. Traditional implementa¬ 
tions have included the trailing null; some new 
implementations have excluded the null. 

One alternative or the other had to be en¬ 
dorsed. The working group decided that 
{_POSIX_PA TH_MAX) should not include the 
trailing null, since specifying this will not 
break currently conforming applications. 

Headers and Name-Space Control: Since 
1003.1b is adding many new identifiers to the 
standard, there was discussion about whether 
new identifiers should be declared in new 
headers, or whether existing headers could be 
used, with new feature-test-macros to control 
visibility of the additional identifiers. It was 
agreed that although both headers and 
feature-test macros control identifier visibility, 
their functions are complementary. Headers 
are appropriately used to divide name-spaces 
horizontally, by functionality. Feature-test 
macros are appropriately used to divide 
name-spaces vertically, by specification level. 

With this understanding, the group de¬ 
cided that new identifiers will be declared in 
the “right place.” A new header will be created 
only if no existing header is functionally 
appropriate. 

A new feature-test macro will be specified 
by 1003.1b and subsequent revisions: 
_POSIX_l_SOURCE. This macro takes ordinal 
values, starting with 2 for 1003.1b, and will be 
incremented by 1 for every subsequent revi¬ 
sion. If the value is 1, the effect will be the 
same as if _POSIX_SOURCE were defined. 

There are two changes here. The new 
name was used to indicate that the macro only 
controls the visibility of identifiers defined in 
POSIX. 1. The usage was changed to allow the 
value to indicate the particular revision or sup¬ 
plement to the standard, rather than having to 
create a new macro each time. This should 
simplify the construction and maintenance of 
header files. 

Requests: Two requests were made by vendors 
trying to support POSIX behavior on non- 
UNIX file systems: 

1. that { _POSIX_LINK_MAX) be reduced 
from 6 to 2 
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2. that { _P0S1X_PATH_MAX) be reduced 
from 255 to 252 

Both requests were rejected. Either of 
these changes could have made existing con¬ 
forming applications non-conforming. Even 
where the risk of breaking applications seemed 
small, the working group was reluctant to set a 
precedent without a pretty good rationale to 
protect them against similar requests in the fu¬ 
ture. 

New Proposals: Five proposals for new inter¬ 
faces were submitted for inclusion in 1003.1b, 
many of which provoked lively discussion. 
Some were accepted, some were rejected, and 
others were deferred to allow a revised 
proposal to be submitted or to allow more 
time for consideration. 

seteuid(), setegidQ: Bob Lenk and Mike Karels 
proposed a set of changes to the way the 
effective user and group id’s are handled, in 
order to provide better support for 
setuid/setgid programs. 

1. Require that all implementations support 
the functionality of the saved user ID and 
saved group ID. These process attributes are 
set by the exec functions and by privileged 
calls to setuidQ and setgidQ. 

2. Add seteuid() and setegidQ as new func¬ 
tions that change only the effective user ID and 
effective group ID, respectively. A change is 
allowed if the proposed new user/group ID is 
the same as either the real user/group ID or the 
saved user/group ID. 

3. Redefine the (_POSIX_SA VEDJDS) option 
to apply only to non-privileged calls to setuidQ 
and setgidQ. 

This proposal has general support in the 
working group, and will be included in the 
next draft of 1003.1b. 

The discussion of this proposal led to a 
general lament about how unclear the group 
model is in the 1988 POSIX standard, perhaps 
the result of a hasty marriage between the 
System V and BSD models. At the next meet¬ 
ing, the working group intends to add new text 
to PI003.lb to clarify the relation between the 
effective group ID and the supplementary 
group list. 


Magnetic Tape Support: The 1003.10 working 
group (Supercomputing Profiles) proposed new 
interfaces to support basic controller functions 
for magnetic tape drives, based on the ioctlQ 
commands supported in 4.3BSD. Although 
support for these interfaces would be optional 
in 1003.1b, the working group decided that the 
functions should be further specified according 
to whether they are: 

1. required for all types of tape drives; 

2. required only for 9-track tape drives; 

3. required only for cartridge tape drives; or 

4. optional on all types of tape drives. 

The proposal needed further revision, but 
was generally supported by the working group. 

The submitted proposal also included in¬ 
terfaces for mounting labeled tape volumes. 
These were considered to be inappropriate for 
inclusion at this time and will be deferred un¬ 
til a later revision of the standard. 

Checkpoint/Restart: The 1003.10 working 
group also proposed new (optional) interfaces 
for checkpointing and restarting processes. 
This proposal is based on two existing imple¬ 
mentations. The interfaces are intended to 
protect very-long-running applications from 
both scheduled shutdowns and unexpected 
failures of the system. 

The 1003.1 working group was not happy 
to have to deal with this and had lots of ques¬ 
tions. Were programming interfaces for port¬ 
able applications really needed, or was a com¬ 
mand interface sufficient? How much state 
needed to be saved in the checkpoint? What if 
the processes depended on additional state in¬ 
formation that was not in the checkpoint, such 
as file data or the states of other communicat¬ 
ing processes or devices? In this case, the 
restart would only be successful if this addi¬ 
tional state had not changed since the check¬ 
point. How could such changes be detected or 
prevented? What is the set of interfaces that 
an application can use and be sure that it can 
be checkpointed and restarted successfully, 
without dependencies on additional state? 
Should applications have a mechanism for 
checkpointing themselves, or for blocking an 
external request that they be checkpointed? 
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Because a checkpoint/restart mechanism 
will have a major impact on implementations, 
and the requirements are not yet clear, the 
working group was unwilling to endorse the 
current proposal. A task force made up of 
representatives of the 1003.1 and 1003.10 
working groups will be created to clarify the 
requirements and revise the proposal. 

This proposal is going to need a lot more 
discussion, so checkpoint restart interfaces will 
almost certainly not be included in P1003.1b, 
but they may be adopted in a subsequent revi¬ 
sion. 

Messaging'. The UniForum proposal for new 
messaging interfaces has been before the 
1003.1 working group for a couple of meetings 
now. The proposed interfaces are intended as 
replacements for the message catalog interfaces 
specified in XPG3, and differ from those in 
several ways (since the discussion was fairly 
contentious, I’ll try to be objective): 

1. The XPG3 interfaces identify a message by 
the triple: ccatalog name, set ID, msg ID>, 
where catalog name is a file name, and set ID 
and msg ID are integers. The UniForum inter¬ 
faces identify a message by the triple: clocale 
name, domain name, message name>, where 
locale name, domain name, and message name 
are all strings. The locale for messages is 
specified by the new LC_MESSAGES category 
of the locale. Advocates of the UniForum 
proposal claim that string identifiers are easier 
to use and are more robust against errors dur¬ 
ing application development and mainte- 
ance. 

2. In the XPG3 scheme, each message catalog 
is an ordinary file. Message catalogs must be 
specified by filename and explicitly opened be¬ 
fore messages can be retrieved. The NLSPATH 
environment variable provides a search path 
for message catalogs that can be parameterized 
by (among other things) the language, territory, 
and codeset fields of the LANG environment 
variable. In the UniForum scheme, groups of 
messages are specified by an abstract 
“domain.” A default domain can be set to con¬ 
trol message accesses, or the domain can be 
explicitly specified for an individual message 
access. Advocates of the UniForum proposal 
claim that the binding of message catalogs to 


files unnecessarily restricts implementations 
and imposes a more complex interface on ap¬ 
plication developers. 

3. The XPG3 interface includes an additional 
string argument that is returned in case no 
message specified by <set ID, msg ID> can be 
retrieved from the message catalog. In the 
UniForum proposal, the message name itself is 
returned if the message cannot be found. Ad¬ 
vocates of the UniForum proposal point out 
that the message name string makes a separate, 
“default” message string unnecessary. 

In addition, the UniForum proposal in¬ 
cludes a specification of the message source file 
format that differs from the format specified in 
XPG3. 

1. In the XPG3 format, message strings are 
implicitly delimited: at the beginning by the 
preceding message ID followed by a single 
space or tab character, and at the end by an 
unescaped newline. In the UniForum format, 
all strings, including domain names, message 
ID’s, and message strings, are explicitly 
delimited by double quotes ("). Adjacent 
strings separated by white-space characters are 
concatenated. Advocates of the UniForum 
proposal claim that the new format provides 
better support for multi-line strings and for 
leading and trailing white-space characters in 
strings. 

2. In the XPG3 format, the message ID and 
its corresponding message string are implicitly 
determined by their position on a source line. 
In the UniForum format, explicit directives 
are provided for message ID’s and message 
strings. Advocates of the UniForum proposal 
claim that the new format is extensible. New 
attributes may be added to message entries, 
such as screen coordinates or font size. 

3. The XPG3 format includes directives for 
deleting individual messages and sets of 
messages, and the associated gencat utility 
takes no switches. In the UniForum proposal, 
all deletion semantics are provided by switches 
on the associated gentext utility. 

There was much discussion of the inter¬ 
faces; less about the source file format. The 
most divisive issue was whether string message 
IDs are preferable to numeric message IDs. 


28 


July/August 1990 



;login: 15:4 


Among those who felt that the new interfaces 
are better, there was disagreement about 
whether the advantages outweighed the cost of 
conversion for applications and implementa¬ 
tions based on the XPG3 interfaces. The ra¬ 
tionale accompanying the UniForum proposal 
described several ways to convert applications 
from the XPG3 interfaces to the proposed new 
interfaces. 

The working group asked X/Open to sub¬ 
mit the XPG3 messaging interfaces as an alter¬ 
nate proposal, since they represent existing 
practice, and X/Open has agreed to do so. 
X/Open has said that they will follow POSIX if 
POSIX endorses a different interface. The 
decision regarding which, if any, messaging 
proposal to include in 1003.1b will be made at 
the POSIX meeting in Danvers. 

It’s hard to predict the fate of this 
proposal. The UniForum proposal represents 
the consensus of one of the leading interna¬ 
tionalization working groups and is reported to 
have some support within X/Open. On the 
other hand, the POSIX working groups are ob¬ 
liged to respect existing practice. Watch this 
space. 

/dev/stdin, /dev/fd/n, etc.: There was an 
unofficial proposal from members of the 
1003.2 working group that openQ be extended 
to recognize the special strings /dev/stdin, 
/dev/stdout, /dev/stderr, and /dev/fd/N, 
and return a new file descriptor dupQed from 
STDIN_FILENO , STDOUT_FILENO , 

STDERR_FILENO , or file descriptor N, respec¬ 
tively. This proposal was intended to allow 
simplified command line parsing, by eliminat¬ 
ing special casing for and “—” arguments. 
The proposal was rejected after a short ex¬ 
ploration of the possible semantics of these 
pathnames when used with linkQ, renameQ, 
etc. 

Conclusion 

As you can see, there’s a lot going on. Even 
though most of the attention has shifted to 
other working groups, the 1003.1 group is busy 
revising and extending the 1988 standard. 
The group is small now, by POSIX standards, 
but their work is as important as ever. 


Report on IEEE 1003.2: 

Shell and tools 

Randall Howard <rand@mks.com> reports on 
the April 23-27 meeting in Salt Lake City, UT: 

Background on POSIX.2 

The POSIX.2 standard deals with the shell 
programming language and utilities. 
Currently, it is divided into two pieces: 

• POSIX.2, the base standard, deals with the 
basic shell programming language and a set of 
utilities required for application portability. 
Application portability essentially means por¬ 
tability of shell scripts and thus excludes most 
features that might be considered interactive. 
In an analogy to the ANSI C standard, the 
POSIX.2 shell command language is the coun¬ 
terpart to the C programming language, while 
the utilities play, roughly, the role of .the C 
library. POSIX.2 also standardizes command¬ 
line and function interfaces related to certain 
POSIX.2 utilities (e.g., popen, regular expres¬ 
sions, etc.). This document is also known as 
“Dot 2 Classic.” 

« POSIX.2a, the User Portability Extension 
or UPE, is a supplement to the base POSIX.2 
standard; it will eventually be an optional 
chapter of a future draft of the base document. 
The UPE standardizes commands, such as 
screen editors, that might not appear in shell 
scripts but are important enough that users 
must learn them on any real system. It is 
essentially an interactive standard that 
attempts to reduce retraining costs incurred by 
system-to-system variation. 

Some utilities have interactive as well as non- 
interactive features. In such cases, the UPE 
defines extensions from the base POSIX.2 
utility. An example is the shell, for which the 
UPE defines job control, history, and aliases. 
Features used both interactively and in scripts 
tend to be defined in the base standard. 

Together Dot 2 Classic and the UPE will 
make up the International Standards 
Organization’s IS 9945/2 — the second volume 
of the proposed ISO four-volume standard 
related to POSIX. 
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In addition to providing current informa¬ 
tion about the activities of the Working and 
Balloting Groups for POSIX.2, a special topic 
of focus will be chosen for each report. There¬ 
fore, the reader is referred to earlier reports for 
information on such topics as the history of 
the Shell Wars and the controversial scope of 
the UPE. The next section talks about the 
functions, rather than utilities that are found 
with POSIX.2. 

The POSIX.2 API Functions 

Perhaps it will come as a surprise to many 
readers that the POSIX Shell and Utilities stan¬ 
dard also contains specifications for about 
fourteen new or extended C function bindings 
- in effect, its own API extending the POSIX. 1 
bindings - as follows: 

confstr(), sysconfO The first function was 
created to provide string-valued configuration- 
specific values such as the default setting of the 
PATH environment variable. The second ex¬ 
tends the POSIX. 1 function of the same name 
with numeric-valued configuration information 
such as the largest scale value in the be utility 
and the implementation’s line length restric¬ 
tion. 

fnmatchQ This functional interface imple¬ 
ments the form of pattern matching used by 
file-name generation (glob) in the shell, case 
statements in the shell, and the -name option 
of the find utility. 

getoptQ This functional interface provides a 
standard utility argument parser that enforces 
the “standard utility syntax” guidelines and 
might be used to implement the getopts utility 
from POSIX.2. 

globQ, globfreeQ This set of functions does 
shell-style file-name generation and presumably 
calls the fnmatchQ function. 

popenQ, pcloseQ This pair of functions, which 
are a part of the standard I/O package on con¬ 
ventional UNIX systems, provides the ability 
to co mmuni cate through pipes to another pro¬ 
cess by executing a string in the POSIX.2 shell 
language. 

regexecQ, regcompQ This set of routines pro¬ 
vides support for both the Basic and Extended 


Regular Expressions defined in POSIX.2, in¬ 
cluding full internationalization support. 

wordexpO, wordfreeO This set of routines pro¬ 
vides a mechanism for an application to use 
word expansion (parameter expansion) that is 
compatible with the POSIX.2 shell language. 
Although most implementations of this routine 
will normally call the shell, it is (at least con¬ 
ceptually) possible that the shell be imple¬ 
mented to call these routines for word expan¬ 
sion. 

systemO This “classical” function executes a 
command written in shell language. 

All of these functions form part of an op¬ 
tional C binding to POSIX.2 and it is expected 
that the soon-to-be-released, draft version of 
the NIST FIPS will make this “optional” func¬ 
tional interface mandatory for US government 
procurements. Other language-binding work¬ 
ing groups, such as those exploring Ada and 
FORTRAN, are presumably encouraged to add 
their own optional bindings if they so wish. 

Although the inclusion of these functions 
seems to be a little out of place in a shell-and- 
tools standard, there is some rationale for this. 
In fact, when POSIX consisted only of 
POSIX. 1, the early attempts to define systemO 
and popenQ made apparent the need to com¬ 
pletely specify the shell language in which the 
argument string to these functions was written. 
That, in turn, along with the desire to stand¬ 
ardize the classical UNIX utility settled to the 
creation of POSIX.2 as the first offshoot group 
in the POSIX family of standards. From this 
beginning, the POSIX. 1 sysconfQ function was 
extended and the confstrQ function was created 
to provide an underlying implementation for 
the getconf utility, which allowed shell-level 
applications to query configuration-specific 
values such as maximum line length of text 
files. Once the beachhead of having functional 
interfaces in POSIX.2 was established, the 
temptation to continually add to this list has 
led to the current list as of Draft 9. 

On the other hand, there are some very 
strong arguments against the inclusion of these 
functions. First, although the regular expres¬ 
sion functions will almost certainly be required 
to implement many POSIX.2 utilities such as 
ed, grep, awk, sed, etc., these functions fall 
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short of the complete support needed to imple¬ 
ment some utilities. For example, the han¬ 
dling of error messages (as in a syntactically 
incorrect regular expression) and the 
mechanisms of doing substitutions (including 
& and \n support) are not addressed. Because 
of this most implementors will be required to 
have “non-portable” proprietary extensions to 
their regular expression support to make a 
“commercially viable” implementation. The 
issue of where to draw the line between inclu¬ 
sion and exclusion is a difficult one indeed. 
Second, vendors and application writers may 
find it difficult, both procedurally and from a 
licensing perspective, to have part of the sub¬ 
routine library come from a POSIX.l developer 
and the other part implemented by the 
POSIX.2 implementor. For example, the im¬ 
plementor of sysconfO, popen(), or systemQ 
might do a much better job if common source 
code and assumptions were possible between 
the POSIX.l and POSIX.2 APIs. 

Status of POSIX.2 Balloting 

“Dot 2 Classic” remains in its second round of 
balloting on Draft 9 with a new draft going to 
ballot in the June to July time frame, accord¬ 
ing to Hal Jespersen, the POSIX.2 Technical 
Editor. 

During the Snowbird meeting, much of 
Monday was devoted to a presentation on the 
status of the Dot 2 Classic Balloting resolu¬ 
tion. It is possible, and indeed likely, that Hal 
Jespersen will limit balloting on Draft 10 to 
unresolved objections and new material. If 
this is the case, it most likely indicates 
(although he didn’t specifically say) that Hal 
has confidence that Draft 10 has a high proba¬ 
bility of achieving the requisite 75% 
affirmative vote. Personally, I am not con¬ 
vinced that this is a likely event. While some 
decisions will be reversed (perhaps several 
times) before Draft 10, the following is a sum¬ 
mary of issues and/or changes appearing in 
Draft 10: 

• The internationalization utilities locale 
and particularly localedef are still controver¬ 
sial, particularly within AT&T. Because of the 
strong rationale for their existence it appears 
that they will remain in Draft 10, certainly 
with considerable amendment as the 


UniForum Technical Committee on Interna¬ 
tionalization refines these newly developed 
utilities. This is just one case where the 
conflict between the role of standards to codify 
existing practice and the obvious holes in ex¬ 
isting practice creates controversy. Perhaps 
this issue will be resolved by a balloting re¬ 
ferendum such as was used for uucp. 

• The Draft 10 shell will almost certainly 
strongly resemble that of Draft 9. Most of the 
important controversies appear to be largely 
settled and most changes appear to be correc¬ 
tions and clarifications. 

• Most complex utilities, such as awk, shell, 
lex, yacc, etc., have undergone extensive re¬ 
working in response to ballot objections. 
Often a seemingly simple objection will cause 
large parts of the description to be rewritten in 
order to tighten it up with respect to complete¬ 
ness and clarity. I believe that Hal Jespersen 
believes that most of these changes are 
uncontroversial and he has ensured this by cir¬ 
culating draft sections via E-mail to various 
“experts.” Certainly, many of these utilities 
desperately needed this clarification. 

• It appears that the newly-engineered hex- 
dump utility is to be replaced by a (much 
simpler) reversion to od. While od is the exist¬ 
ing practice, the POSIX od will be a superset of 
the original one with most useful functionality 
in the new parts. It is not clear that hiding 
new invention under the same name is any less 
controversial than advertising its existence. 

• Of course, there will be innumerable other 
changes, obviously important to many, that 
cannot for reasons of space be covered here. 

A mock ballot on Draft 4 of the UPE was 
sent to the working group during February 
1990 to allow ballot resolution to be the main 
focus of the Salt Lake meeting this April. 

Status of the New Orleans Meeting 

Monday, the working group reviewed the 
current status of the balloting on “Dot 2 
Classic.” This has already been discussed in 
earlier in this report. 

The other four days were spent reviewing 
the 600 to 700 objections produced by the 
mock balloting process for the UPE. While the 
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number of objections seems low compared to 
the rate of objections for the corresponding 
number of pages in Dot 2 Classic, this may 
simply be a symptom of a general shortage of 
time and the lower number of people 
(generally 15 to 20) in the UPE working group. 
This lower number and general lack of time is 
a reflection of the fragmentation of the entire 
POSIX process caused by a proliferation of 
working groups. 

Most of the work during mock balloting 
was of the nature of cleaning up incomplete or 
poorly worded textual descriptions. Particu¬ 
larly controversial issues were often left in the 
rationale for Draft 5. Some controversial utili¬ 
ties were moved to an appendix, based upon 
the belief that they should be removed while 
still allowing the balloting group one last 
chance to save them. The lint89 was one such 
utility whose raison d’etre was meager. At 
best, the functionality probably should be an 
option to c89 in the “Dot 2 Classic” docu¬ 
ment. The sdiff utility, which was inad¬ 
vertently omitted from Draft 4, is to be in¬ 
cluded in Draft 5. 

Altogether, it appears that Draft 5 is in a 
relatively healthy state to survive the rigors of 
the balloting process. Nonetheless, I expect 
that there will be a greater number of objec¬ 
tions in the balloting this summer than there 
were in the mock ballot. 


Report on IEEE 1003.3: Test Methods 

Doris Lebovits <lebovits@attunix.att.com> 
reports on the April 23-27 meeting in Salt 
Lake City, UT: 

Dot three’s job is to do test methods for 
all of the other 1003 standards. The group’s 
work, whose first parts are now in ballot, 
specifies the requirements for OS conformance 
testing for our industry and for NIST. This 
makes what the balloting group and technical 
reviewers are doing, and their schedules, worth 
watching. Pay attention, also, to what comes 
out of the Steering Committee on Confor¬ 
mance Testing (SCCT). Their projects and 
decisions will be interesting and important. 


This was the working group’s sixteenth 
meeting. As usual, we reviewed the ballot 
status of PI003.1 test methods, worked on 
PI003.2 test methods, and reviewed steering 
committee activities. As before, each morning 
we did technical reviews of parts I and II; 
afternoons were spent writing assertions for 
part III. Participants from the usual com¬ 
panies attended (AT&T, NIST, OSF, Mindcraft, 
IBM, DEC, HP, Data General, Cray Research, 
Unisys, Perennial, and Unisoft Ltd.). 

Document structure and some new PARs 

Currently, our evolving document has two 
parts: Part I is generic test methods; Part II is 
test methods for measuring P1003.1 confor¬ 
mance, including test assertions; and Part III 
contains test methods and assertions for 
measuring PI003.2 conformance. (As other 
PI003 standards evolve, they will become 
separate activities in the working group’s 
schedule.) 

After the ballot, each part will become a 
separate standard. Part I will be published as 
IEEE P1003.3; Part II as IEEE P1003.3.1; and 
Part III as IEEE PI003.3.2. To this end, we 
developed and submitted three new PARs to 
the Standards Executive Committee (SEC). 
The PAR for PI003.3 lets Part I apply to all 
TCOS standards (i.e., POSIX). The PAR for 
P1003.3.1 lets Part II include test methods for 
P1003.1 and P1003.1a. The PAR for P1003.3.2 
lets Part III include test methods for P1003.2. 

Ballot status 

Draft 11 of the current ballot, which was re¬ 
circulated to the (approximately) ninety- 
member balloting group late in February, 
closed balloting March 23. Of the 65 respon¬ 
dents, 29 approved, 17 disapproved, and 19 
abstained. This meets the two-thirds response 
requirement, but falls short of the needed 
two-thirds approval. Another re-circulation 
will probably take place in Fall, 1990. 

P1003.2 verification 

This was our fourth meeting working on a 
verification standard for the PI003.2 standard. 
The assertion writing and review were done in 
small groups. Some of the assertions were 
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based upon PI003.2 Draft 9. This group needs 
help from the PI003.2 working group in writing 
test assertions, but no formal arrangement is 
in place yet to provide it. 

Officers for the PI003.2 Test Methods ac¬ 
tivities are: Ray Wilkes (Unisys), Chair; Lowell 
Johnson (Unisys) Secretary; and Andrew 
Twigger (Unisoft Ltd), Technical Editor. 

Steering Committee on Conformance Testing (SCCT) 

The test-methods steering committee is sup¬ 
posed to alleviate the increasing dot-three 
work load all the other proliferating groups are 
creating. Their job is coordinating the activi¬ 
ties of all test-methods groups, monitoring 
their conformance to test methods, and writing 
Project Authorization Requests (PARs). 
Currently, its members are Roger Martin 
(NIST, Steering Committee Chair), Anita 
Mundkur (HP), Andrew Twigger (Unisoft Ltd), 
Bruce Weiner (Mindcraft), and Lowell Johnson 
(Unisys), but membership will be dynamic, 
Right now, this committee is documenting 
procedures. Roger Martin is also clarifying 
which standards the working group will ad¬ 
dress. The Technical Reviewers will review 
this work sometime before the next meeting. 

Report on IEEE 1003.4: 

Real-time Extensions 

Rick Greer <rick@ism.isc.com> reports on 
the April 23-27 meeting in Salt Lake City, UT: 

1003.4 

The .4 ballots went out on schedule, and 
most came back on schedule as well. We 
(barely) got the required 75% response, of 
which 43% approved of the draft as it stood. 
The small-group leaders are currently working 
to resolve the objections and will report back 
at Danvers in July. 

1003.4a 

Most of the work at Snowbird centered around 
threads (.4a). Two alternatives to the pthreads 
proposal were presented at the meeting: 
“strands,” from John Zolnowsky of Sun, 
defined a minimal set of interfaces for 


multi-threaded applications; “VP,” from Paul 
Borman of Cray, added a “virtual processor” 
layer to the pthreads specification, which made 
some multiprocessor (MP) features visible to 
applications. 

The primary MP hardware feature that 
Paul’s VP proposal makes visible to the 
pthreads environment is the ability to write 
your own spin loops and expect them to work. 
One could, for example, have one thread con¬ 
tinuously reading an in-core data base while 
another thread updates it. On an MP system, 
it might be more efficient to code this without 
using a mutex, although doing so on a uni¬ 
processor with a co-routine threads package 
would be an absolute disaster. The new mul¬ 
tiprocessor group, 1003.16, is looking into this 
and similar problems, and will probably sug¬ 
gest that .4a include some sort of system-wide 
attribute structure that one can check when 
writing programs that depend heavily on con¬ 
current execution of threads. 

After a week’s discussion (often a euphem¬ 
ism for argument), we settled into a 
compromise position not that far from where 
we started-pthreads. All this work without 
much net change was frustrating, but probably 
unavoidable. Until fairly recently most of the 
committee was busy getting the .4 draft ready 
for balloting. Lacking enough time to have 
studied threads carefully, members were unwil¬ 
ling to accept the small group’s conclusions be¬ 
fore investigating some alternatives for them¬ 
selves. Still, some progress was made. The 
most important was a more comprehensive 
definition of signal behavior in multi-threaded 
programs. 

1003.14 

On the last day, a first attempt at a real-time 
application environment profile (AEP) was 
presented. This PAR will be an excellent, 
practical test of AEPs. Real-time applications 
are likely to vary wildly in the subsets of .4’s 
rich features that they require. Some worry 
that the real-time AEP will force embedded 
systems that need only one or two .4 features 
to incorporate others just to adhere to the 
standard. The problem this poses is not just 
storage space wasted by unused code, but the 
expense of verifying that this extra code will 
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never get in the way of the application. The 
group will be wrestling with these and similar 
problems in the months to come. 

Report on IEEE 1003.4: 

Real-time Extensions 

John Gertwagen <jag@ism.isc.com> reports 
on the April 23-27 meeting in Salt Lake City, 
UT: 

Administrivia 

PI003 met in Salt Lake City this time. Actu¬ 
ally, it was at Snowbird Lodge, south of and 
well above the city. It was spring in Salt Lake 
but still winter in the mountains. (Wish I 
skied.) The real-time meetings drew 68 people 
the first day, and averaged around 40 all week. 
If some skiers hadn’t deserted each day, we 
would have had more. 

.4 Balloting 

Over 200 people joined the balloting group for 
PI003.4, Draft 9. The first ballot closed in 
mid-March and 75% of balloters returned their 
ballots within a day or two of the official dead¬ 
line, setting a new record! 43% of these voted 
“Yes” on the first round, about average for 
POSIX ballots. 

Lack of time and logistics problems meant 
little ballot feedback by meeting-time (shame 
on those who didn’t submit their ballots elec¬ 
tronically!), but a few issues surfaced. Several 
objected to having binary semaphores only in 
the path namespace and not also in shared 
memory, where they could use simple test- 
and-set calls, and not time-consuming system 
calls. There’s value in providing a common 
interface for both of these and for other “syn¬ 
chronization objects.” 

There were also objections to having 
“events” when there are “fixed” signals in 
System V, Release 4. The technical reviewer 
for events will try to make SVR4 signals meet 
real-time requirements. (Not too long ago, 
there were strong objections to changing sig¬ 
nals. There may still be protests over adding 
real-time-required determinism.) 


Current Work 

With .4 in limbo, the working group got on 
with Threads (.4a), Language Independent 
Bindings (.4b), and Real-time Application En¬ 
vironment Profiles (.14). Threads got the most 
attention. (Surprised?) Despite this, or 
perhaps because of it, the other two drafts saw 
significant progress. 

Rick Greer has reviewed a lot of the 
threads work, so I’ll briefly mention what’s go¬ 
ing on in .4b and .14, give you some personal 
views on threads, and then amplify on areas 
where our editor, Jeff Haemer, was recently 
raked over the coals. 

AEP 

At first, the real-time AEP small group had 
some trouble focusing. They’ve identified two 
fairly easy targets, essentially minimum and 
maxim um configurations, and now seek 
proposals for intermediate specifications. 

In Utah, the group came up with a fairly 
complete specification for embedded systems, 
and reviewed it with PI003.0 *(EM the POSIX 
Guide group that is the driving force in 
defining AEPs. One interesting issue surfaced 
during the review: for embedded systems, the 
AEP group wants to exclude interfaces of .4 
and .1 that aren’t needed! Dot zero hadn’t 
thought of that before. Resolving this should 
set an interesting precedent. 

Language-Independent Bindings 

The people doing this have it down to a sci¬ 
ence, so the large group has largely left them 
alone. Most of their work is converting things 
to “normal” form, which is mostly tabular, 
and throwing away the stuff that is language- 
dependent. They made good use of their time, 
c ranking through a good bit of the .4 draft. 

Threads (P1003.4a) 

The meeting saw two new proposals. Both 
suggested fruitful changes to the current 
Pthreads work, but neither was accepted as a 
new base for the current draft. 

John Zolnowsky of Sun Microsystems sub¬ 
mitted one counter-proposal, called “strands” 
because “threads” was already taken. It was 
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an attempt to limit the scope of the interfaces 
and keep thread semantics closer to process se¬ 
mantics. Thus, it would have done away with 
mutexes and conditions, leaving synchroniza¬ 
tion to be accomplished through .4 binary 
semaphores, presumably modified to have 
inter-thread, not just inter-process, semantics. 
It also proposed more process-like exit seman¬ 
tics and a version of per-thread signaling. The 
consensus on the strands proposal seems to 
have been that it was too minimal. 

In contrast, the VP (Virtual Processor) 
proposal, by Paul Borman of Cray Research, 
proposed significant “incremental” 
functionality in the form of a lower-level 
virtual-processor interface for use by the 
multi-processing and parallel processing com¬ 
munities. (For those familiar with Mach, it ik 
roughly to Pthreads as cthreads is to 
Cthreads.) Features of the VP proposal in¬ 
cluded: 

• fork() and exec() semantics for VPs 

• per-VP signal semantics 

• locks and events for synchronization 

• no ordering or scheduling constraints 
The group had several concerns about VPO 

• Could it support real-time requirements 
without ordering and scheduling constraints? 

• Could the Pthreads constraints be imple¬ 
mented on top of a layer that didn’t support 
them? 

• Would the interfaces be used by applica¬ 
tions or by system implementors? 

• Would an application using both Pthreads 
and VP interfaces encounter analogous 
problems to those caused by readQs and 
freadQs on the same file? 

• Would standard interfaces for locks and 
events, implemented in hardware on many 
systems, constrain or encourage hardware 
development? 

• Would the standard benefit either the user 
or vendor community? 

e How soon could the proposal be com¬ 
pleted and gain enough of the MP 
community’s consensus to go to ballot? 


Perhaps the deciding factor, though, was 
that the multi-processing AEP group (P1003.16) 
started meeting officially at Snowbird. [Editor: 
Watch for the snitch report, coming soon.] A 
majority of our group (including me) felt that 
MP-specific standards should grow from re¬ 
quirements identified by .16, not be created on 
the fly by the real-time working group. 

In areas that are still not pinned down, the 
group made progress towards a better-defined 
cancellation mechanism, towards a “signals 
compromise” that improves on one hurriedly 
forged at the previous meeting, and towards 
more process-like exit semantics. The con¬ 
sensus was that we should try to accommodate 
and specify per-thread signal state. Although 
there are a few strong supporters, a majority 
did not feel that specification of per-thread sig¬ 
nals is essential to a standard. 

Paul Borman of Cray Research will 
present a proposal on this at the next meeting. 
I’ll be interested to see what Paul comes up 
with. With three state elements (mask, pend¬ 
ing signals, and action vector) and at least 
three signal delivery types (one, some, all), I 
can create many implementation models and 
corresponding application architectures. It 
may prove easy to construct a plausible model, 
but hard to construct one that 40 engineers 
can agree to live with for a long time! I 
suspect a portable application can assume 
nothing more than “exactly one signal gets 
delivered exactly once to exactly one handler.” 
(Looks an awful lot likes signals to a process, 
doesn’t it?) 

The biggest progress in the meetings was 
wide consensus achieved for the current 
threads proposal. The working group resolved 
many of the remaining threads issues, and we 
let Bill Corwin tell IEEE/ISO that we expect to 
ballot PI003.4a in July, after the next meeting. 

OSF and UI Cooperating? 

Our editor’s recent editorial stirred up a 
hornet’s nest. (It wasn’t so much what Jeff 
said as what he implied.) In his follow-up post¬ 
ing, he said I’d speak about the joint meetings 
in more detail. I didn’t really want to but he 
twisted my arm, so here goes. 
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The UI MP Working Group and OSF have 
been cooperating since the middle of last year. 
I happen to work for a company that belongs 
to both, INTERACTIVE Systems Corporation, 
and though I haven’t been to all of the joint 
meetings, I’ve attended them off and on since 
last November (which is, I think, when they 
started). Those I have attended focused on 
finding solutions to interface/semantic 
problems that both OSF and UI can endorse 
and that PI003.4 would probably endorse as 
well. Although these meetings haven’t been 
advertised I’ve seen at least one article about 
OSF/UI/ATT negotiations that mentioned their 
cooperation in the MP arena. And the meet¬ 
ings have been open. At least one non¬ 
member has shown up uninvited, and was not 
asked to leave. 

Now, it’s no secret that several Pthreads 
proposal initiators (instigators?) work for OSF 
sponsors. Since the Pthreads-proposal was ad¬ 
vanced before OSF adopted Mach, it’s hard to 
say whether OSF influenced the PI003.4 work 
or the other way around. Also, in several in¬ 
stances, OSF/UI members have voted personal 
opinions contrary to the OSF/UI consensus 
established at the joint meetings. 

What’s the point? The joint meetings con¬ 
tribute to the quality of the .4a work, but they 
don’t drive it. I think the work in PI003.4 is 
pushing vendors to find multi-threading solu¬ 
tions faster than they would have on their 
own. It’s an example of POSIX pushing emerg¬ 
ing technologies, not just creating standards. 
There’s even a chance that .4a will create a 
standard multi-threading interface before mil¬ 
lions of installed heterogeneous systems force 
the standard to a lowest common denominator 
or to incorporate a particular implementation’s 
garbage. 

And POSIX is playing another role - unit¬ 
ing the industry. I believe Sun’s tooth-and- 
nail fights with AT&T in P1003.1 led to their 
current cooperation. Maybe the collaboration 
of OSF and UI on threads will also bring more 
unity to the industry. 


The relationship between .4 and .4a 

Despite what some think, the threads small 
group has never had any official status. In¬ 
terest and participation in the threads effort 
goes far beyond the small group, or even the .4 
working group into other POSIX committees. 
Some history may clear this up. 

Lightweight processes (i.e., threads) have 
been on P1003.4’s list of potential work items 
since its formation. About 3 years ago, the 
working group voted not to pursue them 
because they were not clearly needed and the 
technology was not sufficiently mature. 

About a year and a half ago, threads resur¬ 
faced as an item of interest to the real-time 
users, and also to Ada, Transaction Processing, 
and RPC working groups. A small band of 
“experts” went off to draft a proposal. Since 
PI003.4 was an active system-interfaces com¬ 
mittee and the real-time user community 
wanted a threads proposal, a lot of hard work 
culminated last summer in Minneapolis in a 
threads proposal being accepted as an addi¬ 
tional chapter for the .4 draft. 

There are 12 other interface proposals in 
the .4 draft. Some have been mature for 
nearly two years, (some with broad consensus, 
others without), others are still relatively wet 
behind the ears. Still, all the interfaces are 
relatively complete (sometimes too complete?), 
and in November, when it seemed appropriate 
to send .4 to ballot, .4a wasn’t as complete as 
the rest. At the Milpitas meeting, the PI003.4 
working group decided to include the threads 
chapter in the ballot for comment only, and 
sought and obtained authorization to turn the 
threads work into a separate work item for the 
P1003.4 working group. 

After the Pthreads proposal was accepted 
into .4, the small group of people whose 
primary interest was threads spent all their 
time on threads. Meanwhile many other .4 
members time-shared all the other .4 activities. 
Because the Pthreads supporters were so 
focused, they sometimes seemed like a 
separate group. (Some in the small group 
might have been surprised to learn they 
weren’t. It takes a while to understand the 
POSIX bureaucracy.) Nevertheless, though they 
may not always have appeared to represent the 
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entire working group, the Pthreads proposal 
now enjoys wide consensus. Apparently, the 
small group has listened well to the interests of 
the working group and the POSIX community. 

At Snowbird, there wasn’t a threads small 
group, there were seven of them! These small 
groups examined how the current and the al¬ 
ternative proposals addressed: 

• thread management 

• synchronization 

• signals/asynch events 

• cancellation 

• thread-specific data 

• re-entrant functions 

• process control 

After reviewing all the issues, we 
discovered a consensus in most of these areas, 
and fairly strong agreement on most issues in 
the three or four groups that are still needed. 
It looks like things are pretty well on target. 

I’m partially responsible for pushing .4a in 
before .4 was done, so I’m also partially 
responsible for the process not always appear¬ 
ing fair or well organized. I’ll take my share of 
the blame. But I’ll also take my share of the 
credit for progress in a technology that I be¬ 
lieve to be important for real-time and for the 
entire POSIX community. 


Report on IEEE 1003.5: Ada bindings 

Jayne Baker <cgb@d74sun.mitre.org> reports 
on the April 23-27 meeting in Salt Lake City, 
UT: 

Overview 

The Utah meeting was the group’s first since 
our October meeting in Brussels. In the in¬ 
terim, we had completed a mock ballot of 
Draft 4.0. Jim Lonjers of Unisys, one of our 
two co-chairs, managed the effort. The docu¬ 
ment was mailed out to reviewers on 
December 1, 1989 and comments were due 
January 19, 1990. Although only 16% of the 
ballots were returned, the high quality of the 
comments received made the mock ballot a 


success. Ted Baker, of Florida State Univer¬ 
sity, hosted a special meeting in Tallahassee, 
March 19-23, to resolve issues and comments; 
the result was draft 4.1. We did not attend the 
January New Orleans meeting because bal- 
loters lacked sufficient time to review and re¬ 
turn comments prior to the meeting, though 
some members came to attend other groups’ 
meetings. 

Our main goal in Utah was to prepare the 
Ada Language Binding Document for IEEE 
and ISO Ballot. We addressed the few 
unresolved technical issues from mock ballot; 
read draft 4.1 cover to cover, for accuracy (of 
text and Ada code), content, and consistency; 
established a plan for addressing the ISO for¬ 
matting issues; adopted an optimistic schedule 
for IEEE and ISO ballots; and tried to establish 
a position on threads. 

Unresolved Technical Issues from Mock Ballot 

Most unresolved technical issues from the 
mock ballot were trivial, and quickly resolved. 
They included the details of iterations (e.g., 
through a directory), string lower bounds with 
respect to a string returned by a function, the 
behavior of a file that is opened non-blocking 
when the I/O operation cannot complete, static 
initialization versus “easy implementation” of 
constants, and Text I/O page terminators. 

The most detailed discussion involved 
whether or not files should be closed on an 
Exec. The Ada binding provides a 
Start_Process function, which is a primitive 
that safely creates a new process. In the face 
of Ada tasking, Fork and Exec are unsafe and 
cannot be used to accomplish the results of a 
Start_Process call. Once one of these unsafe 
primitives is issued, an application program is 
no longer under the control of the Ada run 
time system; the operating system is involved. 
Therefore, the integrity of the child process is 
jeopardized, and the state of the process’s I/O 
(i.e., which files are open and closed) is not 
guaranteed. Application programs that must 
be safe with Ada tasking and must have files 
closed and buffers flushed should call 
Start_Process to create a new process. 
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Global Issues Affecting the Document 

We solved several global editorial issues. We 
agreed to use a terse wording style except 
where a more lengthy explanatory style is 
needed for clarity. We accepted the current 
packaging of the Ada code (multiple packages) 
and the non-Ada-Language-Reference-Manual 
coding style. Chapter authors were assigned 
action items to complete their respective refer¬ 
ences and rationale sections. 

We spent a large portion of the meeting 
going through the document chapter-by¬ 
chapter, noting very specific changes. Changes 
recorded in a “master red-lined” copy were 
forwarded to appropriate chapter authors at 
the close of the meeting. These changes will 
be made before the June delivery of the docu¬ 
ment to WG 15. 

ISO Format Issues 

We need to make several minor modifications, 
additions, and deletions before the June WG 
15 meeting, to put the document in ISO stan¬ 
dard format. After the March Tallahassee 
meeting, Jim Moore, of IBM, investigated the 
possibility of hiring a consulting technical edi¬ 
tor to do this work. IBM volunteered to fund 
this effort at a level sufficient to translate the 
document into ISO format, maintain that for¬ 
mat, and make one major edit and two to 
three minor editorial revisions. We accepted 
IBM’s offer, and hired Hal Jespersen. 

Threads Issues 

As in New Orleans, several group members 
met with PI003.4 for threads discussions. 
Most group members feel we should establish 
a position on threads, but we remain firmly di¬ 
vided on what it should be. Several members 
believe the currently defined primitives (i.e., 
the most basic system functions) are 
insufficient, and think that any thread model 
and primitives proposed should be sufficient to 
support Ada tasking, and implement an Ada 
Run-Time. In contrast, at least one group 
member believes we are unrealistic to require 
a threads proposal in C to meet Ada require¬ 
ments - we should, instead, require that C and 
Ada be able to play together in some reason¬ 
able fashion, and have a fair understanding of 


how it will be accomplished. We decided to 
admit our dissension to PI003.4. Interested 
P1003.5 members are acting as liaisons to 
represent their own views, but these liaisons 
do not represent any consolidated P1003.5. 
view. 

The IEEE and ISO ballots 

Steve Deller, our chair, asked the Sponsor’s 
Executive Committee (SEC) to approve our en¬ 
try into the IEEE ballot process. Jim Isaak, 
SEC Chair, met with us early in the week to 
discuss the IEEE and ISO ballot processes and 
help us establish a schedule to reach IEEE and 
ISO ballots simultaneously. Since the ballot 
process seems to be of general interest, here is 
a brief overview. 

A hierarchy of organizations is responsible 
for producing international operating system 
standards and managing the ISO ballot process. 
Two independent international standards or¬ 
ganizations, the International Standards Or¬ 
ganization (ISO) and the International Elec¬ 
trotechnical Committee (IEC), sit on top. 
Joint Technical Committee 1 (JTC 1), a com¬ 
bined effort of these two organizations 
designed to coordinate their efforts in areas of 
overlap, is at the second level; Subcommittee 
22 (SC 22), Languages, at the third; and Work¬ 
ing Group 15 (WG 15), Portable Operating 
Systems for Computer Environments, at the 
fourth. National organizations, such as the 
American National Standards Institute (ANSI), 
mana ge ISO balloting within each country. 
Each participating country has one or more 
representatives in WG 15. The United States 
has a Technical Advisory Group (TAG), which 
meets with and advises the United States’ WG 
15 representatives on the U.S.’s position on 
important issues. 

This bureaucracy requires quite a bit of 
coordination and planning to coordinate IEEE 
and ISO ballots. Most documents require 
about one year to complete the IEEE ballot cy¬ 
cle. Historically, POSIX documents have 
begun with the IEEE ballot process; three to 
four months later, either the original draft, or 
a newer version incorporating IEEE ballot pro¬ 
cess comments, enters the ISO process, and is 
delivered to both WG 15 and SC 22 for appro¬ 
val. Typically, the IEEE ballot is held open 
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until all comments from both IEEE and ISO 
processes are received, reviewed, and incor¬ 
porated. The result is returned to both the 
IEEE and ISO ballot groups for their approval. 
If the IEEE comments are substantive, they 
enter into the ISO process by the submission of 
a United States position. For example, 
P1003.1a is the U.S. position on P1003.1.. 

Our group also initiated formation of a 
formal ballot group - the group that will actu¬ 
ally vote on the current draft. We will deliver 
Draft 5.0, in ISO format, to WG 15 at the Ada 
Europe meeting this June. Draft 6.0 will go to 
IEEE ballot on August 6. If we receive the re¬ 
quired 75% response by September 21, the bal¬ 
lot will close immediately; if not, we must 
reconsider the ballot group membership, and 
revise our schedule. In early October, draft 6.0 
will be delivered to SC22. At the October 
meeting, in Seattle, we will resolve the IEEE 
ballot comments and produce Draft 7.0, which 
will enter the ISO Ballot process. At the Janu¬ 
ary 1991, New Orleans Meeting, we will deter¬ 
mine whether a second IEEE Ballot is needed. 
Any changes to Draft 7.0 resulting from a 
second IEEE Ballot will be entered into the ISO 
process through a pro forma objection. There 
are no guarantees, but PI003.5 could reach 
Draft International Standard (DIS) status by 
late second quarter of 1991. 

Conclusion 

The April ’90 Salt Lake City Meeting was a 
success. We addressed the issues we hoped to 
address and attained our goal for the meeting. 
We also established a schedule for reaching 
IEEE and ISO ballot; although this schedule is 
optimistic, we think we can meet it. 


Report on IEEE 1003.6: Security 

An anonymous source reports on the April 
23-27 meeting in Salt Lake City, UT: 

Apologia 

This is my first and last review as a snitch. 
[Editor: We thank you for doing it, and hope 
your circumstances change to allow you to file 
more.] In it, you’ll see no party line. My views 
will sometimes be controversial, and I hope 


they spark discussion and feedback. They 
represent neither the views of my company 
nor of its clients - I’m submitting this 
anonymously so no one can misconstrue them 
as being my company’s - and they’re certainly 
not meant to represent the consensus of the 
1003.6 Working Group. 

I’ll put my biases on the table. I’m a com¬ 
mercial user and commercial software pro¬ 
vider, not a government user, government 
software provider, or UNIX vendor. To some 
degree, these biases have influenced the com¬ 
mittee, since I’ve been active in the group 
since its inception and attended every 1003.6 
meeting. With that perspective, let’s begin. 

Overview 

The 1003.6 Working Group is putting together 
a Department-of-Defense-inspired version of 
UNIX. Our efforts will help vendors sell 
systems to the U.S. Government and its con¬ 
tractors. All our interfaces will make it easier 
to evaluate conforming systems at one of the 
DoD’s Trusted Computer Security Evaluation 
Criteria (TCSEC) levels. This is not inherently 
bad, but it does sell the commercial and inter¬ 
national communities short. (More on this 
later.) 

The working group is considering four 
areas: Discretionary Access Control (DAC), 

Mandatory Access Control (MAC), Least 

Privilege, and Audit. 

Discretionary Access Control: The DAC group’s 
job is hard. They are devising an Access Con¬ 
trol List (ACL) mechanism that must co-exist 
with the familiar user, group, other 

mechanism. ACLs are discretionary because 
the user, not the system, decides each object’s 
access rights. The traditional user, group, 

other mechanism is also discretionary: file 
protections are specified by the user. ACLs ex¬ 
tend this by allowing users to grant different 
access permissions to arbitrary lists of named 
users and groups. (In other words, the tradi¬ 
tional mechanism is an ACL with exactly three 
entries.) Designing an ACL is easy; maintaining 
compatibility with chmod, stat, umask, and the 
file creation mask of creat isn’t. 

Mandatory Access Control: MAC is another 
type of access control mechanism. All system 
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objects get a security label and all system users 
have a security classification set by the system 
or the Security Administrator (Systems Ad¬ 
ministrator). Users have no control over this 
mechanism’s application; objects created by a 
user of classification X automatically receive a 
security label of X. Only users with 
appropriate classifications can access or 
modify a system object. (As a useful, if inex¬ 
act, analogy, think of the way UNIX automati¬ 
cally assigns file ownerships.) 

The TCSEC security criteria’s popularity 
and widespread acceptance have given MAC 
another connotation - that of a codification of 
the familiar U.S. government, hierarchical 
security classifications: Top Secret, Classified, 
and Unclassified. Government policy prohibits 
users of a lower classification from viewing 
work of a higher classification. Conversely, 
users at a high classification may not make 
their work available to users at a lower 
classification: one can neither “read up” nor 
“write down.” There are also compartments 
within each classification level, such as NATO, 
nuclear, DOE, or project X. Access requires the 
proper level and authorization for all compart¬ 
ments associated with the resource. The MAC 
group is defining interfaces for such a manda¬ 
tory mechanism. It’s not as confusing as it 
sounds, but outside of the DoD it is as useless 
as it sounds. (Prove me wrong. Show me how 
this DoD policy is useful in a commercial en¬ 
vironment.) 

Least Privilege: The Least Privilege group is 
eliminating root. They’re creating both a list 
of privileges to encompass all of root’s special 
uses (e.g., set-uid to a different user-id, create a 
directory, create a file system, override DAC 
protection) and a mechanism to inherit, assign, 
and enable those privileges. 

Audit: The Audit group is preparing a standard 
interface for a logging mechanism, a standard 
format for logging records, and a list of system 
calls and commands to log. 

Standards 

At the ISO level, there will be no separate 
security standard. Our work will be merged 
with the 1003.1 (System Interface), 1003.2 
(Commands and Utilities), and 1003.7 (System 


Administration) work in the ISO 9945-1, -2, 
and -3 standards. This means every conform¬ 
ing system will include security mechanisms. I 
like this. Do you? 

Scope and motivation 

All 1003.6 members feel we are making POSIX 
secure, not merely helping sell systems to the 
U.S. government. Our work is important and 
necessary (except, of course, MAC), but I think 
our focus has been too narrow. We included 
mechanisms for the TCSEC criteria but 
stopped there. We haven’t sought out the 
work of other countries. We haven’t con¬ 
sidered the work being done in international 
standards bodies such as ISO and CCITT. We 
haven’t explicitly considered commercial users. 
We’ve limited ourselves to helping provide 
TCSEC-conforming systems. Many of us be¬ 
lieve that the TCSEC criteria are good for com¬ 
mercial applications. Is that hopeful claim just 
self-serving? We don’t know. I wish eminent 
computer scientists and researchers had gotten 
together to study the needs of commercial 
users and drawn up an independent set of 
commercial security requirements. But they 
didn’t. 

Kevin Murphy, of British Telecom, is the 
ISO/IEC JTC1/SC22/WG15 security rapporteur - 
he formally represents the international 
community’s concerns and views. In January, 
Kevin brought several of these to the working 
group’s attention, including our TCSEC biases 
and lack of attention to ISO activities. The 
international set seems to consider the 
document’s constant references to the TCSEC 
work provincial and inconsiderate of other 
countries’ requirements. They also feel we 
should be more aware and accepting of ISO 
terminology in the document. Kevin also says 
our scope is too limited in the CCITT X.400 
and X.500 areas. 

Snowbird 

Plenary: The meeting opened with a short 
plenary session. This time, the first topic of 
discussion was the progress of the 1003.6 draft 
document. Mike Ressler, of Bellcore, accepted 
the position of technical editor and brought a 
new draft of 1003.6, which contained work of 
all but the Audit subgroup. In addition, an 
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electronic copy of the document was available 
for the subgroups to modify and update during 
the meeting. The technical editor position had 
been open since October. No draft was avail¬ 
able during this time, which worried us since it 
prevented us from setting any realistic comple¬ 
tion date. With a draft in hand and a techni¬ 
cal editor we now project completion in April, 
1991. 

Charlie Testa’s absence meant we lacked 
our usual detailed report on TRUSIX. 
(TRUSIX is a DoD-sponsored organization 
made up of the National Computer Security 
Center, AT&T, and several other companies.) 
Rick Sibenaler and Shaun Rovansek, of the 
NCSC, gave us a brief update, reporting that 
the audit rationale will be available at the July 
POSIX meeting and that select experts are now 
reviewing the draft version of their formal 
model, which is written in a formal 
verification language, INA JO. 

Some of the work of TRUSIX augments 
the work of 1003.6 - pursuit of a formal 
security model and descriptive top-level 
specification, and a mapping between them, 
for example - but some overlaps. I’m still 
puzzled over why TRUSIX has pursued audit 
and DAC mechanisms when 1003.6 is doing 
the same work. (Another challenge: can any¬ 
one out there tell me?) To their credit, 
TRUSIX is accomplishing their goals much fas¬ 
ter than 1003.6. For example, Charlie 
reported in January that the TRUSIX DAC 
work is already complete. This speed may be 
at the expense of POSIX, since many very good 
people in both organizations are forced to split 
time between the two unnecessarily. 

Mike Ressler reported on the networking 
and administration and security liaison group, 
which spends an afternoon at every POSIX 
meeting discussing mutual concerns of these 
three independent working groups. Here are 
the liaison group’s goals, in areas of our com¬ 
mon interest: 

• identify areas of overlapping or missing 
coverage, 

• provide an interface to ISO, ECMA, 
CCITT, and other international bodies, and 


• exchange ideas and discuss related issues. 

Peter Cordsen, of DataCentralen (Den¬ 
mark), presented Danish security require¬ 
ments. They define three levels of sensitivity, 
with criminal data among the most sensitive. 
There was no specific comparison to either the 
U.S. TCSEC or the emerging European security 
criteria. Peter suggested that the security 
working group begin addressing authentica¬ 
tion, a position that received much support 
from other representatives. 

Draft work: After the plenary, we worked on 
the document in subgroups. 

Discretionary Access Control (DAC)\ The group 
put together a new outline for the general and 
introductory sections of the draft and rewrote 
those sections to follow the new outline. They 
also resolved several issues: 

• There will be only one type of default 
ACL, not the previously planned separate types 
for regular files and directories. 

• A mask entry type has been added to pro¬ 
vide a mechanism that temporarily overrides 
all other entries without actually changing 
their values or deleting them from the ACL. 
The feature also fits nicely with the current 
plan for ACL interaction with the old POSIX 
permission bits. 

• The user model for both default and ac¬ 
tual ACLs will be the same. (The internal 
representations are undefined.) System inter¬ 
faces will be the same, too. A flag will be ad¬ 
ded to any interfaces that need to be able to 
distinguish the two. 

Audit: Olin Sibert, of Sun, presented a new 
compromise audit proposal, based on an ear¬ 
lier one by Kevin Brady, of AT&T, and Doug 
Steves, of IBM, which he thought resolved 
some of the earlier work’s problems. The 
working group accepted Olin’s proposal with 
minor changes and incorporated it into Draft 
6, which was distributed in the IEEE May 
mailing. 

Mandatory Access Control (MAC): Since Kevin 
Brady, the MAC chair, was participating in the 
Audit discussion, and Chris Hughes, of ICL, 
the acting chair, was also absent, Joe Bulger, of 
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NCSC, ran the meeting. It is still unclear who 
will chair the MAC subgroup. 

Through the joint efforts of Bellcore and 
AT&T, the MAC draft had been translated 
from a proprietary word-processor format into 
the [n|t]roff + POSIX-macro format required 
for inclusion in the draft standard. The MAC 
draft’s contents had been stable for several 
meetings, so the group spent the entire week 
changing the document. 

This group seems to be having the most 
difficulty getting its job done. There doesn’t 
seem to be as much discussion and active par¬ 
ticipation in the MAC group as the others. 

Privileges: No functional changes were made 
to the privileges material at this meeting, but 
significant changes were made to the rationale. 
The group also firmed up concepts and disam¬ 
biguated functional ambiguities. 

Networking, Administration, and Security 
Liaison: The networking, administration, and 
security liaison group held its second meeting 
Wednesday afternoon. The meeting, chaired 
by Mike Ressler, started by reviewing the 
group’s scope and goals. 

Since there had been no ISO meeting since 
the January POSIX meeting, Yvon Klein, of 
Group Bull (France), didn’t have anything new 
to say about ISO’s security activities. 

As part of the group’s continuing efforts to 
identify problem areas, the system administra¬ 
tion group and two networking groups gave 
presentations on their work. Steve Carter, of 
Bellcore, presented the scope and charter of 
the system administration group, 1003.7, and 
explained their use of an object-oriented 
paradigm. Jim Oldroyd, of the Instruction 
Set, followed this by presenting the work of 
1003.7’s interoperability subgroup. 

Kester Fong, of General Motors, gave an 
overview of the FTAM group. He left us with 
the impression that there wasn’t much room 
for collaboration, but we’ll surely need to 
review the relationship between the file¬ 
system’s security semantics and those of 
FTAM. 

Jason Zions, of HP, gave one of the most 
interesting and aggressive presentations of the 


day, on the work of the Transparent File Ac¬ 
cess Group, which included a preliminary list 
of issues that 1003.8 feels need to be reviewed. 

Finally, David Rogers, of ICL (Britain), 
gave a presentation on the European security 
criteria. He predicted harmonization by June 
1990 of the work of Britain, France, Germany, 
and Holland. The European criteria will 
define separate levels of functionality and as¬ 
surance. There will be ten classes of 
functionality. The first five are hierarchical 
and are similar to the U.S. Orange-Book 
criteria; the remaining five address particular 
security needs, such as integrity, availability, 
and networks. There are seven classes of as¬ 
surance. A product evaluated under these 
criteria is likely to receive a rating from the 
first five functional classes, one or more of the 
next five functional classes, and an assurance 
rating. 

Final Comments: With the short plenary ses¬ 
sion, the availability of the draft document in 
electronic form, and the presence of many 
lap-top systems to work on, this meeting was 
one of our most productive. The group seems 
to have picked up enthusiasm from the 
knowledge that our work is coming together 
and the end is in sight. 

Report on IEEE 1003.7: 

System Administration, 

Interoperability Subgroup 

Jim R. Oldroyd <jr@inset.com> reports on 
the April 23-27 meeting in Salt Lake City, UT: 

POSIX has given P1003.7 a charter to 
define both command-line and applications- 
programming interfaces for administering mul¬ 
tiple networked machines from a central point. 
Most reports on this group seem to focus on 
the group’s object-oriented approach: the ad- 
ministerable classes the group is defining, their 
attributes (properties) and their operators. 
[Editor: Martin Kirk has promised us a report 
on this. Watch for it soon.] 

Sometimes overlooked in this object- 
oriented frenzy is another, equally important. 
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and perhaps more difficult goal of the group: 
interoperability. 

Imagine, for example, an administrator 
who wishes to execute an operation on some 
fraction of nodes in a large, heterogeneous net¬ 
work of POSIX systems. The administrator 
wants to be able to issue the request once - 
and at his or her own terminal. The system 
should take care of determining which actual 
objects are affected and of communicating the 
request to them. 

How should this be done? The fact that 
today’s networks are heterogeneous means that 
it is not sufficient for vendors simply to supply 
systems with a consistent set of administerable 
object classes. Nor is it enough for vendors to 
define a consistent set of commands and API 
names that operate on these classes. On top of 
this, there has to be a consistent language for 
systems from different vendors to communi¬ 
cate with each other in order to tell each other 
that changes have to be made to some of the 
objects they are supporting. 

The P1003.7 Interoperability subgroup is 
defining a standard protocol for communica¬ 
tion with remote objects. 

Currently, we are trying to work out the 
protocol’s requirements. The protocol will 
have to support varied system-management 
philosophies. Some operations, such as re¬ 
enabling all PostScript^ printers, should be 
queued and executed independently for each 
target. Failure to enable one printer does not 
mean that the other printers should remain 
disabled. Others operations must be atomic 
over the domain, for example, when adding a 
user to a set of machines, it is necessary to 
confirm that a UID is available on all target 
machines before adding the user to any 
machine. 

Each of these problems saddles the pro¬ 
tocol with a different requirement. The former 
case could be handled by broadcasting an in¬ 
struction and collecting success or failure 
reports later; the latter requires a two-phase 
commit, requesting confirmation that 


t PostScript is a trademark of Adobe Systems, Inc. 


successful completion is possible throughout 
the domain before actually mandating the 
change. 

Do we have to invent a new protocol from 
scratch? P1003.7 is actively studying existing 
protocols, such as ISO’s CMIP/CMIS and the 
Internet SNMP. Both of these are existing 
protocols designed to manage objects across 
multiple systems - exactly as per P1003.7’s 
needs. However, both of these are actually 
designed to manage the network itself, and it 
is not clear that they lend themselves to 
management of things like users, printers, and 
filesystems (etc.) properly. We hope to dis¬ 
cover whether some existing protocol will fill 
the bill in the next few meetings. 

The Interoperability subgroup of PI003.7 
will continue work in this area at our next 
meeting (Danvers, MA, July 16-20). If you are 
an interested party, we want to hear from you. 


Report on IEEE 1003.9: 

FORTRAN bindings 

Michael Hannah <mjhanna@sandia.gov> 
reports on the April 23-27 meeting in Salt 
Lake City, UT: 

FORTRAN bindings committee prepares to go to 
ballot 

The FORTRAN bindings committee is prepar¬ 
ing the official call for a ballot group. Because 
the POSIX work is all done under the auspices 
of the IEEE Technical Committee on Operating 
Systems Standards Subcommittee (TCOS-SS), 
all members of the ballot group must be both 
regular IEEE or Computer Society members, 
and members of the TCOS-SS (no extra charge 
to join). Non-members may submit infor¬ 
mative ballots, but such ballots cannot count 
towards the required response percentage 
(75%), or percentage of affirmative responses 
(also 75%) required for passage of the stan¬ 
dard. [Editor: Institutional Representatives 
are exceptions to this rule. See IEEE 1003.1- 
1988, p. 177 for a detailed explanation of the 
rules.] 

For more information, the appropriate 
membership forms, and instructions for 
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returning the forms to the proper IEEE offices, 
contact the committee chair, John McGrory, at 
the address listed at the end of this article. 
This information and sign-up packet will be 
available by the end of June, but you may con¬ 
tact the chair as soon as you want your name 
added to the distribution list. 

The formal sign-up period is expected to 
be August 15 through October 19, 1990. The 
ballot period is expected to last from 
November 9, 1990 through January 4, 1991. 
We are especially eager to attract a large 
representative balloting group, and encourage 
interested individuals to sign up. While the 
views represented on the P1003.9 working 
group have been appropriate and varied, the 
number of active members has been small 
(typically, around a dozen). 

Some history 

As the committee prepares to go to ballot, it 
might be of value to review some of the more 
sticky issues that the working group has ad¬ 
dressed. The formal adopted charter of the 
committee is to provide access to the POSIX- 
defined standard operating system interface 
and environment, directly from the FORTRAN 
language. There are two major issues of scope 
that bear comment: “Access to how much of 
POSIX?” and “Which FORTRAN?” 

Some POSIX features are easily imagined 
as useful to a FORTRAN application (e.g., 
chmod, exec, etc.); some are less easily 
imagined (pick your favorite obscure system 
call). It was unclear where to draw the line, so 
the committee took the approach of ensuring 
access to all features defined in 1003.1 (IEEE 
1003.1-1988, or ISO/IEC 9945-1:1990). It 
seemed clear that full functional access would 
be provided by most vendors, so full standard¬ 
ization seemed called for. Some diehard C 
language addicts continue to ask, “Why have 
any FORTRAN bindings?” Although most ven¬ 
dors provide a method of calling C functions 
from FORTRAN, they vary from vendor to 
vendor. Further, any library of C routines 
provided by a vendor to map FORTRAN 
constructs to the POSIX defined procedures is 
bound to differ among vendors. The PI003.9 
bindings are silent on implementation, so the 
FORTRAN subprograms defined in the 


bindings could be implemented as just such a 
library. The bindings just standardize the in¬ 
terface. Keeping in mind the POSIX goal of 
application portability, only a truly complete 
FORTRAN binding would provide portability 
of any FORTRAN application. 

A harder issue was, “Which FORTRAN?” 
Our choices were: 

1. FORTRAN 77 [ANSI X3.9-1978, ISO 1539- 
1980 (E)], 

2. a codification of common extensions & 
enhancements to FORTRAN 77, or 

3. the revised FORTRAN standard emerging 
from the ANSI X3J3 committee *(EM previ¬ 
ously referred to as FORTRAN 8X but now 
called Fortran 90. (The working group has 
been delighted to have an officially appointed 
representative of X3J3 as an active member.) 
[Editor: Note that Fortran 90 will finally let us 
type the name of the language without using 
the caps-lock key. “And gain is gain, however 
small.” - Robert Browning] 

We chose the first. 

For FORTRAN 77 vs. Fortran 90, we were 
swayed by the fact that FORTRAN 77 is 
currently the only adopted standard. (Fortran 
90 is scheduled to be adopted as an ANSI stan¬ 
dard after PI003.9 goes to ballot.) Further, 
FORTRAN-77-based applications are expected 
to exist for some years. Thus, the working 
group felt that FORTRAN-7 7-based bindings 
would be of value to the user community. The 
working group expects to develop a new set of 
bindings, based solely on Fortran 90, after 
completion of the FORTRAN 77 bindings (and 
after the Fortran 90 standard is adopted). One 
result of this decision is a Subprogram-naming 
scheme that reflects the version of the language 
(e.g., CALL F77MKDIR(...) ). This will ensure 
that there will be no name-space conflict with 
similar-purpose subprograms in a future 
Fortran 90 binding. 

An even harder issue, once we decided to 
base the bindings on FORTRAN 77, was 
whether to define the bindings as extensions 
and/or enhancements to the language itself, or 
simply as a library of callable FORTRAN 
subprograms. While the latter was finally 
chosen, there was considerable argument for 
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the former. In fact, one extension to 
FORTRAN 77 was considered minimally essen¬ 
tial. The current document requires the 
language to differentiate external names 
unique to 31 characters, even though the 
FORTRAN 77 standard limits them to six. 
The extension seems harmless. Fortran 90 
specifies uniqueness to 31 characters and all 
current FORTRAN 77 compilers researched 
provide this extension. Further, since the list 
of PI003.9 subprogram names is finite, if 
necessary, a vendor could provide a preproces¬ 
sor to convert these names into unique strings 
of six characters. 

If the PI003.9 bindings had defined 
changes to the language itself, then major miss¬ 
ing constructs in the FORTRAN 77 language 
needed for easy POSIX access (most notably, 
structures and pointers) could have been pro¬ 
vided by choosing either the emerging Fortran 
90 constructs or an existing vendor solution. 
At first the working group felt that this might 
be required for some access features. How¬ 
ever, as we struggled with each issue, working 
papers and proposals were introduced that 
resolved every one with callable FORTRAN 
subprograms (though some might argue about 
elegance or ease of use). While we mostly 
steered clear of “ease-of-implementation” ar¬ 
guments, since we viewed the FORTRAN 77 
bindings as an interim, we felt that vendors 
would be quicker to implement a library of 
subprograms than modifications to compilers. 

A final hard question of standard scope 
concerned whether to restrict the standard to 
1003.1, or expand it to general FORTRAN- 
application portability issues, both within and 
outside the POSIX arena. Both a lack of 
resources and a desire to provide timely bind¬ 
ings on the heels of 1003.1 made us decide to 
limit the scope to 1003.1 functionality. 

As other base standards are produced 
(e.g., 1003.2, 1003.4, etc.), we expect to 
construct and ballot bindings for those stan¬ 
dards. For example, we have worked with 
PI003.2 in defining a standardized command 
to invoke the FORTRAN compiler (after a 
number of iterations, now named fort7T) which 
is part of their current draft. Actual P1003.9 
bindings to 1003.2 might include definitions of 
additional utilities of use to FORTRAN 


applications not mentioned in the base 1003.2 
standard (e.g J77split, f77lint, etc.). 

Another argument against adding features 
was that many, if not most, of the problems 
we saw in portability are solved by new 
constructs in Fortran 90. Many of us felt that 
as a standards group we should only provide a 
minimum set of features for “perhaps-soon- 
to-be-obsolete” FORTRAN 77, and thereby 
speed up the date for providing full bindings 
to the new Fortran 90, which provides more 
features for application portability. 

How to get involved 

If you have strong feelings about these issues, 
the most effective avenue to express them at 
this point is to join the balloting group being 
formed. Nevertheless, if you wish to discuss 
them before this you can also directly contact 
the chair (John McGrory) or me (vice-chair, 
Michael Hannah), or join the e-mail discussion 
group. Addresses follow: 

PI003.9 Chair: 

John McGrory 
Hewlett Packard Co. 

Division 2615 
19046 Pruneridge Avenue 
Cupertino, Ca 95014 
mcgrory%hpda@HPLABS.HP.COM 

P1003.9 ViceChair: 

Michael Hannah 
Sandia National Labs 
Albuquerque, NM 87185 
mjhanna@SANDIA.GOV 

Un-moderated mailing list: 
posix-fortran@SANDIA.GOV 

To join the list, send request to: 
posix-fortran-request@SANDIA.GOV 

Report on 1003.12: 

Protocol-Independent Interfaces 

Andy Nicholson <droid@earth.cray.com> 
reports on the April 23-27 meeting in Salt 
Lake City, UT: 
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Introduction 

For starters, we’ve had some significant turn¬ 
over. [Editor: Including, you’ll note, Steve 
Head, our former fine dot 12 snitch. Thanks 
for diving in, Andy.] We are now down to five 
participants who were present a year ago, are 
on our third AT&T representative, and an HP 
representative has permanently left the work¬ 
ing group. Despite all this, the group is begin¬ 
ning to make rapid advances on both the 
Simplified (SNI) and Detailed (DNI) network 
interfaces. This meeting’s progress is sketched 
below. 

Overview of the Work We’re Doing 

The dot 12 committee is working on three pro¬ 
jects: Simplified Network Interface (SNI), 
Detailed Network Interface (DNI), and Data 
Representation Interface (DRI). Work on DRI 
is being delayed until SNI and DNI are well 
along. DNI is a protocol-independent inter¬ 
face to network services that allows access to 
protocol-dependent features in a protocol- 
independent manner. DNI is meant to pro¬ 
vide a complete interface to everything you 
might expect to be able to do with networking 
services. DNI is comparable to Berkeley Sock¬ 
ets or AT&T’s TLI, and we plan that anything 
that can be accomplished with those interfaces 
will be subsumed by DNI. 

The idea behind SNI is that many applica¬ 
tions will not require “detailed” access to net¬ 
working services. SNI gives a “stdio” type of 
interface for networking that combines com¬ 
mon groupings of procedures, eliminates ac¬ 
cess protocol-dependent features, and is just 
plain easier to use. Applications that use SNI 
aren’t necessarily simple, they just don’t need 
DNI’s detailed access to networking services. 

Simplified Network Interface 

We started the week discussing the SNI inter¬ 
face. Norm Smith, from Unisys, had intended 
to bring an alternate SNI proposal to this meet¬ 
ing, but his group at Unisys decided to work 
with the current one. Irene Hu, from DEC, 
says she may yet offer an alternate proposal. 

I presented a paper, prepared from previ¬ 
ous minutes, which gathered up some deferred 
issues relating to SNI and we resolved some of 


them. For example, we added some explicit 
goals for SNI that everyone seemed to have ac¬ 
cepted implicitly, but were never made official. 

We also considered creating a formal 
definition of SNI functionality, to help us 
determine whether any particular function 
should be included, but decided it would be 
more efficient to keep deliberating each case 
individually. We’ll record the rationale for 
each as part of the standard document to help 
us avoid and respond to ballot objections. 

• SNI functionality 

A paper by Tim Kirby (who works with me at 
Cray Research) prompted the group to redefine 
a function call. Sni_recv(), was defined to 
discard excess data in a datagram when the 
buffer offered by an application isn’t large 
enough. The new version of Sni_recv(), allows 
an application either to discard excess data or 
to perform multiple snijrecv() calls to read it 
all. It also allows applications to discard 
datagrams without reading them at all. Here, I 
think the group has noticeably extended the 
power of the interface without sacrificing 
efficiency. 

• Kernel objects 

Because SNI endpoints may not be kernel ob¬ 
jects, we need to define semantics and inter¬ 
faces that will allow SNI endpoints to survive 
execQ. Unfortunately, we disagree on the se¬ 
mantics of the endpoint-preservation pro¬ 
cedures. Should multiple copies of the same 
endpoint exist in different processes’ address 
spaces, as happens with forkQ and execQl Im¬ 
plementing the protocol stack in a user library 
creates multiple copies of state information for 
the same endpoint, and it may be impossible 
to keep them synchronized. 

Some of us (Keith Sklower, from Berkeley, 
the author of the SNI document, and I) want 
to restrict endpoint semantics so that only one 
process may have a copy of an SNI endpoint; 
others (Irene and Norm) disagree and wish to 
allow multiple copies of SNI endpoints where 
the programmer wishes. 
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Detailed Network Interface 

We discussed DNI procedures in detail for the 
first time and found tentative agreement on 
most of the many issues raised. Mike Karels, 
from Berkeley’s Computer Science Research 
Group, presented an outline of required 
functionality. After discussing it, we agreed to 
make DNI endpoints POSIX file descriptors (as 
returned by open()) until we see a compelling 
counter-argument. I’ll challenge you to offer 
one. 

On Wednesday, Irene gave an overview of 
XTI. During the presentation, Torez Hiley, 
our new attendee from ATT, told us that XTI 
is being revised: input from vendors using the 
Berkeley socket interface is prompting the ad¬ 
dition of many features. Torez will report on 
the upcoming revision at the July meeting. 
Where sockets and XTI/TLI differ, the best 
solution is not clear. Moreover, some features 
are absent or inadequately supported in both 
interfaces. Here, we have a lot of work to do 
and are just getting started. We’re eager to 
hear whether the new XTI solves any of our 
problems. 

Report on IEEE 1003.14: 
Multiprocessing 

Bill Cox <bill@attunix.att.com> reports on 
the April 23-27 meeting in Salt Lake City, UT: 

The POSIX Multiprocessing Study Group 
had its first official meeting as PI003.14 in 
Utah, where the SEC approved its Project 
Authorization Request (PAR) for a Multipro¬ 
cessing Execution Environment Profile. Mul¬ 
tiprocessing systems have become cost- 
effective means for providing computing 
power, but with the advantages come some 
specific concerns that need to be addressed at 
the interface level. The goal of this work is to 
try to make POSIX safe for multiprocessing; a 
secondary goal is to try to make POSIX 
hospitable for multiprocessing. POSIX work¬ 
ing groups do not necessarily share the con¬ 
cerns of the implementors and users of mul¬ 
tiprocessing systems. 

Bob Knighten (Encore) is the Chair, Bill 
Cox (AT&T UNIX Software Operation) is 


Secretary, and Dave Plauger (Affiant) is the 
Technical Editor. Officers must have a com¬ 
mitment of support from their employers, to 
ensure that they can attend working group 
meetings and devote necessary time to the pur¬ 
poses of the working group. 16 people at¬ 
tended the group meetings. 

People interested in .4A (threads) have 
tended to be interested in .14 and vice versa. 
Many .14 members that have been meeting 
with P1003.4/.4A see substantial problems with 
pthreads in a multiprocessor environment, and 
I know at least eight people working on .4A 
that want to come work in .14. 

The working group designated one official 
liaison to .4A, who was joined by two other 
tentative volunteers. We will also establish 
liaisons with .1, .6, .7, .8, .10, and .12. 

During the week, we spent time in three 
areas. 

1. We clarified the group’s work items, and 
started work on the most important, the Appli¬ 
cation Environment Profile. (An AEP may 
specify relevant portions of other POSIX 
working groups’ work, make choices where op¬ 
tions are permitted, and specify behavior that 
a [draft] standard may have left undefined or 
unspecified.) 

2. We discussed current conventional wis¬ 
dom on multiprocessing. The discussions cen¬ 
tered around presentations by BBN, Cray, 
Encore, AT&T USO, and Affiant on lessons 
they’ve learned. 

3. We created two small groups. 

The first began work on high-level require¬ 
ments placed on pthreads by multiprocessing. 
Attendees included Rick Greer (Interactive), 
Mary Weeks (Sun), and Bill Cox (AT&T USO). 
Here are some requirements we feel strongly 
about: 

• A library implementation of “user-level 
threads” is vitally important. User-level 
threads often must be multiplexed onto 
kernel-supported objects/processes/threads, 
largely for performance reasons. These 
kernel-supported objects, etc, are sometimes 
called “virtual processors,” because they sup¬ 
port an abstraction closer to that of a physical 
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processor, with interrupts/signals, and a 
significant amount of state. .4A should not 
deal with threads at this virtual processor 
level. 

• The formal memory model of P1003.4/D9 
section 13.1 must apply to .4A. This model 
defines the semantics of memory interaction 
that should be preserved in a multithreaded or 
multiprocessing environment. 

• Global threads scheduling makes little 
sense in a multiprocessor, though such 
scheduling could be useful as a hint (like C’s 
register declarations if you don’t have 
enough registers). Global policy is difficult to 
implement in a multiplexed thread environ¬ 
ment. 

• use of attribute structures for mutual ex¬ 
clusion variables (in particular, for scheduling 
hints) 

• Locks shouldn’t be opaque, and program¬ 
mers should be able to statically initialize 
them. The latter is important so that locks 
can be part of data structures, and not require 
time-consuming dynamic allocation and ini¬ 
tialization. 

• There must be only one set of libraries. 
There are performance reasons to have single- 
threaded libraries, i.e., libraries that are not 
thread-aware, for a uniprocessor or single- 
threaded applications. The group believes that 
the cost of maintaining such libraries is 
sufficiently high that a non-reentrant library or 
set of libraries should not be required. 

The other group began work on the AEP 
itself. 

Members of this small group, and their 
responsibilities, included 

Dave Plauger (Alliant) — skeleton for the 
document, 

Frank Lawlor (IBM) — checkpoint restart, 
review, and liaison with .10 and .7, 

James Gibson (BBN) — review and liason with 

• 2 , 

Bob Knighten (Encore) — review and liason 
with .4, and 


Tom Weaver (IBM) — review and liason with 
.1 and .6. 

This group identified several areas of con¬ 
cern: 

• microtasking models 

• checkpoint, snapshots, and core dump 
format/synchronization 

• a general programming model 

• dividing the “reading list” (other PI003 
standards and drafts) 

• determining focus (are we dealing with 
portability for application writers, users, 
and/or administrators?) 

• standardizing system services 

A sketch of the planned document in¬ 
cludes: 

• reference to TIMS 

• multithreaded applications (.4A) 

• HLL parallel applications (PCF FORTRAN, 
parallel C) 

• IPC 

Report on ANSI X3B11.1: 

WORM File Systems 

Andrew Hume <andrew@research.att.com> 
reports on the April 17-19 meeting in Tucson, 
AZ: 

Introduction 

X3B11.1 is working on a standard for file inter¬ 
change on write-once, non-sequential (random 
access) media: a portable file system for 
WORMs. This was our fourth meeting. With 
many major issues somewhat settled, our main 
remaining decisions are how to implement 
directory hierarchies and how to manage free 
space. 

Multi-Volume Sets 

WORM file systems store a fair amount of in¬ 
formation per file (such as most of the fields in 
struct stat), per directory, per partition, and 
per volume. A volume is a logical address 
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space associated with a piece of physical 
media. For example, a WORM disk that can 
only be accessed one side at a time would be 
two volumes. Each volume has a label block 
describing its size, partitions, directory hierar¬ 
chies, free space management, and so on. 
(Free space management is discussed below; 
for now, this could mean a pointer to the next 
free block.) 

Informally, multi-volume sets means hies 
and directories can be spread over several 
volumes. Here are some requirements for this 
feature: 

• A file can be bigger than a volume (file 
sizes are limited to 2**64 bytes). 

• You can append to a file. 

• You can update any part of a file. 

• All volumes need not be simultaneously 
accessible. (That is, if you have a three 
volume set, you don’t need three drives.) 

• Each volume, and the whole volume set, 
must be consistent after an update. 

• Usable, although perhaps not fast, on a 
single drive. The idea is that you can’t man¬ 
date that the control structures for the volume 
set be distributed over the set, because that 
would mean that on single-drive systems, users 
might have to mount every volume to recover 
even a single file. We would like to require 
only that the user mount the volume the file is 
on and perhaps one other (the master volume). 

• Each volume must be self-contained (for 
disaster recovery), 

• Security control is per volume, directory, 
and file. 

After convincing ourselves that we all 
spoke roughly the same language, we came to 
consensus decisions for the following ques¬ 
tions: 

• Can a file description point to extents 
(files are spread across a list of extents) on 
later volumes? (Yes) 

• Can a directory entry point to a file 
description on a later volume? (Yes) 

• Must a directory be completely contained 
on a single volume? (No) Why? There’s no 


reason to require it. All implementations are 
likely to use the same primitives to manage 
files and directories (that is, they’ll implement 
directories as files); if you can handle multi¬ 
volume files correctly, directories should be 
easy too. Some people were concerned about 
being able to get the directory in one (more or 
less) I/O or block (especially for MS-DOS) but 
that can’t happen in general; directories and 
files are likely to be spread all over the 
volume. 

• must all the file descriptions for a single 
directory hierarchy fit on a single volume? (no) 

• should each volume of a volume set point 
to the volume describing the root of the main 
directory hierarchy for that set? (yes) 

The above involve subtleties not readily 
apparent; details available on request. 

Directory Hierarchies 

Much discussion centered on how to imple¬ 
ment directory hierarchies - at least, after our 
initial surprise discovery that we are commit¬ 
ted to support multiple directory hierarchies. 
This commitment comes from the CD-ROM 
standard, ISO 9660, where the intent was to 
have an ASCII directory tree and one or more 
national-character-set trees. 

[Editor: CD-ROMs, like WORMs, are on 
write-only media, but solve different problems. 
Both provide tremendous storage capacity, but 
CD-ROMs appear to the user to be read-only, 
while WORMs appear to provide read and 
write access. Nevertheless, on WORMs, writ¬ 
ing to a file means either appending characters 
to a preallocated chunk of disk, or rewriting a 
new version of the file in a new place. Once a 
file, or file version, is discarded, the piece of 
the physical medium it’s stored on is forever 
lost, not released for reuse. CD-ROMs are for 
storing the Encyclopedia Britannica; WORMs 
are for storing backups.] 

Our basic choice is between what I call the 
scattered directory tree, which is much like the 
standard, UNIX file system, and path tables 
(linearized encodings of the tree structure). 
ISO 9660 supports both. Scattered directories 
are simpler to deal with and somewhat easier 
to update, but probably slow to access because 
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they require too much seeking. Path tables 
seem faster at first glance (large contiguous 
reads, etc.), but their simplicity and speed 
seem to evaporate when the tables are 
modified. There is no consensus on which 
method to use. I originally held out for two 
methods, a flexible one and a really fast one, 
but have come to the conclusion, reinforced by 
conversations with Ken Thompson, that it is 
better to have one flexible method in the stan¬ 
dard - scattered directories - and handle ac¬ 
celerators, such as directory trees cached on 
magnetic disk, as system-dependent structures 
outside the standard. 

Suppose you update a file; doesn’t that 
mean you also have to rewrite the directory, 
and, therefore, its parent directory, and, there¬ 
fore, its parent directory, and so on all the way 
up to the root directory? And the volume 
header? How do you find the root directory, 
the volume header, and so on? This stuff is 
not yet decided but we envision that the file 
description stuff will have preallocated spare 
space so that a few updates can be done 
without changing anything outside the file 
description. Once this space is full, the system 
will have to get free space elsewhere, which 
implies updating some other area describing 
the free space. The volume header is in a 
fixed location (probably 8KB in from the start 
of media) and will point to any later volume 
headers and other stuff (such as where the root 
of the various directory trees are). 

Requirements for the directory hierarchy 
include space and time efficiency, robustness 
(e.g., to minimize damage from a single I/O 
error), a single fast structure (unlike ISO 9660’s 
two), and that a directory entry for a file must 
be complete (that is, point to all the extents for 
that file). 

Space Allocation and Management 

We must support preallocation of space (e.g., 
“Reserve 40MB of contiguous space for file 
‘xyz’.”) both for speed and to support systems 
like the Macintosh. Because of the latter, we 
also need to support giving back unused 
reserved space for later use. 

These two requirements appear to force 
the standard to address describing the free 


space in a volume set, which will also be im¬ 
portant if the standard is extended to cover 
R/W optical disks, where freed blocks need to 
be cleared before reuse. The two choices ap¬ 
pear to be run-length encodings of the free 
space or bitmap techniques. The former can 
degrade to being quite large, while the latter 
have a fixed, but high, overhead (current 
media hold up to 8.2GB/side!). 

Finale 

We hope to conduct a letter ballot soon after 
the October 1990 meeting. If we can approve 
a proposal by January 1991 then it may be an 
ANSI standard by January 1992. Our next 
meeting is in Murray Hill, New Jersey, on July 
17-19, where we expect to adopt the proposal 
being edited by Howard Kaikow as our work¬ 
ing proposal. Anyone interested in attending 
should contact either the chairman, Ed 
Beshore (edb@hpgrla.hp.com), or me 
(andrew@research.att.com). 

While this standard may seem of limited 
interest, because it deals only with WORMs, 
X3B11.1 expects approval shortly to develop a 
similar standard for R/W optical media. It 
doesn’t take much imagination to see that 
standard being extended to apply to all rewrit¬ 
able direct-access media. (Unlike the CD-ROM 
standards committee, which ignored UNIX, 
this committee has a significant number of 
UNIX users, including representatives from 
AT&T Bell Labs, Sun, Hewlett-Packard. That, 
at least, ensures filenames won’t be required to 
have a compulsory three-character suffix and a 
version number.) Once we have a working pa¬ 
per, anyone who cares about portable, multi¬ 
volume, multiple-character-set file systems 
should take a look. [Editor: Pay attention. 
He’s giving you fair warning.] 


Report on Recent Standards Activities 

Jeffrey S. Haemer <jsh@ico.isc.com> reports 
on spring-quarter standards activities: 

This editorial is an overview of some of 
the spring quarter standards activities covered 
by the USENIX Standards Watchdog Com¬ 
mittee. A companion article provides a 
general overview of the committee itself. 
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In this article, I’ve emphasized non¬ 
technical issues, which are unlikely to appear 
in official minutes and mailings of the stan¬ 
dards committees. Previously published arti¬ 
cles give more detailed, more technical views 
on most of these groups’ activities. If my 
comments move you to read one of those ear¬ 
lier reports that you wouldn’t have read other¬ 
wise, I’ve served my purpose. Of course, on 
reading that report you may discover the 
watchdog’s opinion differs completely from 
mine. 

SEC: Standard/Sponsor Executive Committee 

The biggest hullabaloo in the POSIX world 
this quarter came out of the SEC, the group 
that approves creation of new committees. At 
the April meeting, in a move to slow the 
uncontrolled proliferation of POSIX standards, 
the institutional representatives (IRs) (one 
each from Usenix, UniForum, X/Open, OSF, 
and UI) recommended two changes in the Pro¬ 
ject Authorization Request (PAR) approval 
process: (1) firm criteria for PAR approval and 
group persistence and (2) a PAR approval 
group that had no working-group chairs or co¬ 
chairs. Dale Harris, of IBM Austin, presented 
the proposal and immediately took a lot of 
heat from the attendees, most of whom are 
working-group chairs and co-chairs. (Dale 
isn’t an IR, but shared the concerns that 
motivated the recommendations and asked to 
make the presentation.) 

The chair, Jim Isaak, created an ad hoc 
committee to talk over the proposal in a less 
emotional atmosphere. Consensus when the 
committee met was that the problem of proli¬ 
ferating PARs was real, and the only question 
was how to fix it. The group put together a 
formal set of criteria for PAR approval (which 
John Quarterman has posted to 
comp.std.unix), which seems to have satisfied 
everyone on the SEC, and passed without 
issue. The criteria seem to have teeth: at least 
one of the Project Authorization Requests 
presented later (1201.3, UIMS) flunked the 
criteria and was rejected. Two others (1201.1 
and 1201.4 toolkits and Xlib) were deferred. I 
suspect (though doubt that any would admit it) 
that the proposals would have been submitted 
and passed in the absence of the criteria. In 


another related up-note, Tim Baker and Jim 
Isaak drafted a letter to one group (1224, 
X.400 API), warning them that they must ei¬ 
ther prove they’re working or dissolve. 

The second of the two suggestions, the 
creation of a PAR approval subcommittee, 
sank quietly. The issue will stay submerged so 
long as it looks like the SEC is actually using 
the approved criteria to fix the problem. 

Shane McCarron’s column in the July 
Unix Review covers this area in more detail. 

1003.0: POSIX Guide 

Those of you who have read my last two 
columns will know that I’ve taken the position 
that dot zero is valuable, even if it doesn’t get 
a lot of measurable work done. This time, I 
have to say it looks like it’s also making 
measurable progress, and may go to mock bal¬ 
lot by its target of fourth quarter of this year. 
To me, the most interesting dot-zero-related 
items this quarter are the growing prominence 
of profiles, and the mention of dot zero’s work 
in the PAR approval criteria passed by the 
SEC. 

A1 Hankinson, the chair, tells me that he 
thinks dot zero’s biggest contribution has been 
popularizing profiles - 

basically, application-area-specific lists of 
pointers to other standards. This organizing 
principle has been adopted not only by the 
SEC (several of the POSIX groups are writing 
profiles), but by NIST (Al’s from NIST) and 
ISO. I suspect a lot of other important organi¬ 
zations will fall in line here. 

Nestled among the other criteria for PAR 
approval, is a requirement that PAR proposers 
write a sample description of their group for 
the POSIX guide. Someone questioned why 
proposers should have to do dot zero’s job for 
them. The explanation comes in two pieces. 
First, dot zero doesn’t have the resources to be 
an expert on everything, it has its hands full 
just trying to create an overall architecture. 
Second, the proposers aren’t supplying what 
will ultimately go into the POSIX guide, 
they’re supplying a sample. The act of draft¬ 
ing that sample will force each proposer to 
think hard about where the new group would 
fit in the grand scheme, right from the start. 
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This should help ensure that the guide’s ar¬ 
chitecture really does reflect the rest of the 
POSIX effort, and will increase the interest of 
the other groups in the details of the guide. 

1003.1: System services interface 

Dot one, the only group that has completed a 
standard, is in the throes of completing a 
second. Not only has the IEEE updated the 
existing standard-the new version will be IEEE 
1003.1-1990-ISO appears on the verge of 
approving the new version as IS 9945-1. The 
major sticking points currently seem limited to 
things like format and layout - important in 
the bureaucratic world of international stan¬ 
dards, but inconsequential to the average user. 
Speaking of layout, one wonders whether the 
new edition and ISO versions will retain the 
yellow-green cover that has given the current 
document its common name-the ugly green 
book. (I’ve thought about soaking mine in 
Aqua Yelva so it can smell like Green Char¬ 
treuse, too.) 

The interesting issues in the group are 
raised by the dot-one-b work, which adds new 
functionality. (Read Paul Rabin’s snitch 
report for the gory details.) The thorniest 
problem is the messaging work. Messaging, 
here, means a mechanism for access to exter¬ 
nal text and is unrelated to msggetQ, msgopQ, 
msgctlQ, or any other message-passing 
schemes. The problem being addressed is how 
to move all printable strings out of our 
programs and into external “message” files so 
that we can change program output from, say, 
English to German by changing an environ¬ 
mental variable. Other dot-one-b topics, like 
symbolic links, are interesting, but less per¬ 
vasive. This one will change the way you 
write any commercial product that outputs 
text - anything that has printfQ statements. 

The group is in a quandary. X/Open has 
a scheme that has gotten a little use. We’re 
not talking three or four years of shake-out, 
here, but enough use to lay a claim to the “ex¬ 
isting practice” label. On the other hand, it 
isn’t a very pleasant scheme, and you’d have 
no problem coming up with alternative candi¬ 
dates. The UniForum Internationalization 
Technical Committee presented one at the 
April meeting. It’s rumored that X/Open itself 


may replace its current scheme with another. 

So, what to do? Changing to a new scheme ig¬ 
nores existing internationalized applications 
and codifies an untried approach. Blessing the 
current X/Open scheme freezes evolution at 
this early stage and kills any motivation to 
develop an easy-to-use alternative. Not pro¬ 
viding any standard makes internationalized 
applications (in a couple of years this will 
mean any non-throw-away program) non¬ 
portable, and requires that we continue to 
have to make heavy source-code modifications 
on every port - just what POSIX is supposed 
to help us get around. 

To help you think about the problem, 
here’s the way you’ll have to write the “hello, 
world” koan using the X/OPEN interfaces: 

#include <atdio.h> 

#include <nl_types.h> 

#include <locale.h> 
mainO 

nl.catd catd; 

(void)setlocale(LC_ALL. 

/* error checking omitted for brevity */ 

catd = catopenC'hello", 0) ; 

printf(catgets(catd, 1, 1, "hello, world\n". 

> 

and using the alternative, proposed UniForum 
interfaces: 

#include <stdio.h> 

#include <locale.h> 
mainO 

(void)setlocale(LC_ALL, ""); 
(void)textdomain("hello M ); 
printf(gettext("hello, world\n")); 

> 

I suppose if I had my druthers. I’d like to 
see a standard interface that goes even farther 
than the UniForum proposal: one that adds a 
default message catalogue/group (perhaps 
based on the name of the program) and a stan¬ 
dard, printf-f amily messaging function to hide 
the explicit gettextQ call, so the program could 
look like this: 

#include <stdio.h> 

#include <locale.h> 
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#define printf printmsg 
main() 

< 

/* inescapable, required by ANSI C */ 
(void) setlocale(LC_ALL, 
printf("hello, world\n"); 

> 

but that would still be untested innovation. 

The weather conditions in Colorado have 
made this a bonus year for moths. Every 
morning, our bathroom has about forty moths 
in it. Stuck in our house, wanting desperately 
to get out, they fly toward the only light that 
they can see and beat themselves to death on 
the bathroom window. I don’t know what to 
tell them, either. 

1003.2: Shell and utilities 

Someone surprised me at the April meeting by 
asserting that 1003.2 might be an important 
next target for the FORTRAN binding group. 
(“What does that mean?” I asked stupidly. “A 
standard for a FORTRAN-shell?”) Perhaps 
you, like I, just think of dot two as language- 
independent utilities. Yes and no. 

First, 1003.2 has over a dozen function 
calls (e.g., getoptQ). I believe that most of 
these should be moved into 1003.1. SystemQ 
and popenQ, which assume a shell, might be 
exceptions, but having sections of standards 
documents point at things outside their scope 
is not without precedent. Section 8 of 
P1003.1-1988 is a section of C-language exten¬ 
sions, and P1003.5 will depend on the Ada 
standard. Why shouldn’t an optional section 
of dot one depend on dot two? Perhaps ISO, 
already committed to regrouping and 
renumbering the standards, will fix this. 
Perhaps not. In the meantime, there are func¬ 
tions in dot two that need FORTRAN and 
Ada bindings. 

Second, the current dot two standard 
specifies a C compiler. Dot nine has already 
helped dot two name the FORTRAN com¬ 
piler, and may want to help dot two add a 
FORTRAN equivalent of lint (which I’ve 
heard called “flint”). Dot five may want to 
provide analogous sorts of help (though Ada 
compilers probably already subsume much of 
lint’s functionality). 


Third, more subtle issues arise in provid¬ 
ing a portable utilities environment for 
programmers in other languages. Numerical 
libraries, like IMSL, are often kept as single 
large source files with hundreds, or even 
thousands, of routines in a single / file that 
compiles into a single .o file. Traditional 
FORTRAN environments provide tools that 
allow updating or extraction of single subrou¬ 
tines or functions from such objects, analogous 
to the way ar can add or replace single objects 
in libraries. Dot nine may want to provide 
such a facility in a FORTRAN binding to dot 
two. 

Anyway, back to the working group. 
They’re preparing to go to ballot on the UPE 
(1003.2a, User Portability Extensions). The 
mock ballot had pretty minimal return, with 
only ten balloters providing approximately 500 
objections. Ten isn’t very many, but mock 
ballot for dot two classic only had twenty- 
three. It seems that people won’t vote until 
they’re forced to. 

The collection of utilities in 1003.2a is 
fairly reasonable, with only a few diversions 
from historic practice. A big exception is 
ps(l), where historic practice is so heterogene¬ 
ous that a complete redesign is possible. Un¬ 
fortunately, no strong logical thread links the 
1003.2a commands together, so read the ballot 
with an eye toward commands that should be 
added or discarded. 

A few utilities have already disappeared 
since the last draft. Pshar, an implementation 
of shar with a lot of bells and whistles, is gone. 

compress /uncompress poses an interesting 
problem. Though the utility is based on clear- 
cut existing practice, the existing implementa¬ 
tion uses an algorithm that is copyrighted. 
Unless the author chooses to give the algo¬ 
rithm away (as Ritchie dedicated his set-uid 
patent to public use), the committee is faced 
with a hard choice: 

• They can specify only the user interface. 
But the purpose of these utilities is to ease the 
cost of file interchange. What good are they 
without a standard data-interchange format? 

• They can invent a new algorithm. Does it 
make sense to use something that isn’t field 
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tested or consistent with the versions already 
out there? (One assumes that the existing ver¬ 
sion has real advantages, otherwise, why would 
so many people use a copyrighted version?) 

Expect both the first real ballot of 1003.2a 
and recirculation of 1003.2 around July. Note 
that the recirculation will only let you object 
to items changed since the last draft, for all the 
usual bad reasons. 

1003.3: Test methods 

The first part of dot three’s work is coming to 
real closure. The last ballot failed, but my 
guess is that one will pass soon, perhaps as 
soon as the end of the year, and we will have a 
standard for testing conformance to IEEE 
1003.1-1988. 

That isn’t to say that all is rosy in dot-one 
testing. NIST’s POSIX Conformance Test 
Suite (PCTS) still has plenty of problems: 
misinterpretations of dot one, simple timing 
test problems that cause tests to run well on 
3b2’s, but produce bad results on a 30 mips 
machine and even real bugs (attempts to read 
from a tty without first opening it). POSIX 
dot one is far more complex than anything for 
which standard test suites have been 
developed to date. The PCTS, with around 
2600 tests and 150,000 lines of code, just 
reflects that complexity. An update will be 
sent to the National Technical Information 
Service (NTIS-also part of the Department of 
Commerce, but not to be confused with NIST) 
around the end of September which fixes all 
known problems, but with a suite this large, 
others are likely to surface later. 

By the way, NIST’s dot one suite is a 
driver based on the System V Verification 
Suite (SWS), plus individual tests developed 
at NIST. Work has begun on a suite of tests 
for 1003.2, based, for convenience, on a suite 
done originally for IBM by Mindcraft. It isn’t 
clear how quickly this work will go. (For ex¬ 
ample, the suite can’t gel until dot two does.) 
For the dot one work, NIST made good use of 
Research Associates-people whose services 
were donated by their corporations during the 
test suite development. Corporations gain an 
opportunity to collaborate with NIST and in¬ 
side knowledge of the test suite. I suspect 


Roger Martin may now be seeking Research 
Associates for dot two test suite development. 
If you’re interested in doing this kind of work, 
want to spend some time working in the 
Washington, D.C. area, and think your com¬ 
pany would sponsor you, his email address is 
rmartin@swe. ncsl. nist.gov. 

By the way, there are a variety of organi¬ 
zational and numbering changes happening in 
dot three. See Doris Lebovits’s snitch report 
for details. 

The Steering Committee on Conformance 
Testing (SCCT) is the group to watch. Though 
they’ve evolved out of the dot three effort, 
they operate at the TCOS level, and are about 
to change the way POSIX standards look. In 
response to the ever-increasing burden placed 
on the testing committee, the SCCT is going to 
recommend that groups producing new stan¬ 
dards include in those standards a list of test 
assertions to be used in testing them. 

Groups that are almost done, like 1003.2, 
will be grandfathered in. But what should be 
done with a group like dot four-not far enough 
along that it has something likely to pass soon, 
but far enough to make the addition of major 
components to its ballot a real problem. 
Should this case be treated like language in¬ 
dependence? If so, perhaps dot four will also 
be first in providing test assertions. 

1003.4: Real-time extensions 

The base dot-four document has gone to bal¬ 
lot, and the ensuing process looks like it may 
be pretty bloody. Fifty-seven percent of the 
group voted against the current version. (One 
member speculated privately that this meant 
forty-three' percent of the balloting group 
didn’t read it.) Twenty-two percent of the 
group (nearly half of those voting against) 
subscribed to all or part of a common refer¬ 
ence ballot, which would require that entire 
chapters of the document be completely 
reworked, replaced, or discarded. Subscribers 
to this common reference ballot included em¬ 
ployees of Unix International and the Open 
Software Foundation, of Camegie-Mellon 
University and the University of California at 
Berkeley, and of Sun Microsystems and 
Hewlett-Packard. (USENIX did not ballot 
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similarly, but only because of lack of time.) 
Some of these organizations have never before 
agreed on the day of the week, let alone the se¬ 
mantics of system calls. But then, isn’t bring¬ 
ing the industry together one goal of POSIX? 

Still, the document has not been returned 
to the working group by the technical editors, 
so we can assume they feel hopeful about 
resolving all the objections. Some of this hope 
may come from the miracle of formality. I’ve 
heard that over half of the common reference 
ballot could be declared non-responsive, which 
means that there’s no obligation to address 
over half the concerns. 

The threads work appears to enjoy a more 
positive consensus. At least two interesting al¬ 
ternatives to the current proposal surfaced at 
the April meeting, but following a lot of 
discussion, the existing proposal stood largely 
unchanged. I predict that the threads work, 
which will go to ballot after the base dot four 
document, will be approved before it. John 
Gertwagen, dot four snitch and chair of 
UniForum’s real-time technical committee, has 
bet me a beer that I’m wrong. 

1003.5: Ada bindings & 

1003.9: FORTRAN-77 bindings 

These groups are coming to the same place at 
the same time. Both are going to ballot and 
seem likely to pass quickly. In each case, the 
major focus is shifting from technical issues to 
the standards process and its rules: forming 
balloting groups, relations with ISO, future 
directions, and so on. 

Here’s your chance to do a good deed 
without much work. Stop reading, call some¬ 
one you know who would be interested in 
these standards, and give them the name of 
someone on the committee who can put them 
into the balloting group. (If nothing else, point 
them at our snitches for this quarter: Jayne 
Baker, cgb@d74sun.mitre.org, for dot five, and 
Michael Hannah, mjhanna@sandia.gov, for 
dot nine.) They’ll get both a chance to see the 
standard that’s about to land on top of their 
work and a chance to object to anything that’s 
slipped into the standard that doesn’t make 
sense. The more the merrier on this one, and 
they don’t have to go to any committee 


meetings. I’ve already called a couple of 
friends of mine at FORTRAN-oriented com¬ 
panies; both were pleased to hear about 
1003.9, and eager to read and comment on the 
proposed standard. 

Next up for both groups, after these stan¬ 
dards pass, is negotiating the IEEE standard 
through the shoals of ISO, both getting and 
staying in sync with the various versions and 
updates of the base standard (1003.1a, 
1003.1b, and 9945-1), and language bindings 
to other standards, like 1003.2 and 1003.4. 
(See my earlier discussion of dot two.) Notice 
that they also have the burden of tracking their 
own language standards. At least in the case 
of 1003.9, this probably means eventually hav¬ 
ing to think about a binding to X3J3 (Fortran 
90). 

1003.6: Security 

This group has filled the long-vacant post of 
technical editor, and so is finally back in the 
standards business. In any organization whose 
ultimate product is to be a document, the tech¬ 
nical editor is a key person. [We pause here to 
allow readers to make some obligatory cheap 
shot about editors.] This is certainly the case 
in the POSIX groups, where the technical edi¬ 
tors sometimes actually write large fractions of 
the final document, albeit under the direction 
of the working group. 

I’m about to post the dot six snitch report, 
and don’t want to give any of it away, but will 
note that it’s strongly opinionated and chal¬ 
lenges readers to find any non-DoD use for 
Mandatory Access Control, one of the half- 
dozen areas that they’re standardizing. 

1003.7: System administration 

This group has to solve two problems at 
different levels at the same time. On the one 
hand, it’s creating an object-oriented definition 
of system administration. This high-level 
approach encapsulates the detailed implemen¬ 
tation of objects interesting to the system ad¬ 
ministrator (user, file system, etc.), so that 
everyone can see them in the same way on a 
heterogeneous environment. On the other 
hand, the protocol for sending messages to 
these objects must be specified in detail. If it 
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isn’t, manufacturers won’t be able to create in¬ 
teroperable systems. 

The group as a whole continues to get 
complaints about its doing research-by- 
committee. It’s not even pretending to stand¬ 
ardize existing practice. I have mixed feelings 
about this, but am unreservedly nervous that 
some of the solutions being contemplated 
aren’t even UNIX-like. For example, the 
group has tentatively proposed the unusual 
syntax object action. Command names will be 
names of objects, and the things to be done to 
them will be arguments. This bothers me (and 
others) for two reasons. First, this confuses 
syntax with semantics. You can have the 
message name first and still be object-oriented; 
look at C++. Second, it reverses the tradi¬ 
tional, UNIX verb-noun arrangement: mount 
filesystem becomes filesystem mount. This flies 
in the face of the few existing practices every¬ 
one agrees on. I worry that these problems, 
and the resulting inconsistencies between 
system administration commands and other 
utilities, will confuse users. I have a recurring 
nightmare of a long line of new employees out¬ 
side my door, all come to complain that I’ve 
forgotten to mark one of my device objects, 
/dev/null, executable. 

With no existing practice to provide a 
reality check, the group faces an uphill strug¬ 
gle. If you’re an object-oriented maven with a 
yen to do something useful, take a look at 
what this group is doing, then implement some 
of it and see if it makes sense. Look at it this 
way: by the time the standard becomes reality, 
you’ll have a product, ready to ship. 

1003.10: Supercomputing 

This group is working on things many of us us 
old-timers thought we had seen the last of: 
batch processing and checkpointing. The 
supercomputing community, condemned for¬ 
ever to live on the edge of what computers can 
accomplish, is forced into the same approaches 
we used back when computer cycles were 
harder to come by than programmer cycles, 
and machines were less reliable than software. 

Supercomputers run programs that can’t 
be run on less powerful computers because of 
their massive resource requirements 


(cpu/memory/io). They need batch processing 
and checkpointing because many of them are 
so resource-intensive that they even run for a 
long time on supercomputers. Nevertheless, 
the supercomputing community is not the only 
group that would benefit from standardization 
in these areas. (See, for example, my com¬ 
ments on dot fourteen.) Even people who have 
(or wish to have) long-running jobs on work¬ 
stations, share some of the same needs for 
batch processing and checkpointing. 

Karen Sheaffer, the chair of dot ten, had 
no trouble quickly recasting the group’s 
proposal for a batch PAR into a proposal that 
passed the SEC’s PAR approval criteria. The 
group is modeling a batch proposal after exist¬ 
ing practice, and things seem to be going 
smoothly. 

Checkpointing, on the other hand, isn’t 
faring as well. People who program supercom¬ 
puters need to have a way to snapshot jobs in 
a way that lets them restart the jobs at that 
point later. Think, for example, of a job that 
needs to run for longer than a machine’s 
mean-time-to-failure. Or a job that runs for 
just a little longer than your grant money lasts. 
There are existing proprietary schemes in the 
supercomputing world, but none that’s port¬ 
able. The consensus is that a portable 
mechanism would be useful and that support 
for checkpointing should be added to the dot 
one standard. The group brought a proposal 
to dot one b, but it was rejected for reasons 
detailed in Paul Rabin’s dot one report. 
Indeed, the last I heard, dot-one folks were 
suggesting that dot ten propose interfaces that 
would be called from within the program to be 
checkpointed. While this may seem to the 
dot-one folks like the most practical approach, 
it seems to me to be searching under the 
lamp-post for your keys because that’s where 
the light’s brightest. Users need to be able to 
point to a job that’s run longer than an¬ 
ticipated and say, “Checkpoint this, please.” 
Requiring source-code modification to accom¬ 
plish this is not only unrealistic, it’s un- 
UNIX-like. (A helpful person looking over my 
shoulder has just pointed out that the lawyers 
have declared “UNIX” an adjective, and I 
should say something like “un-UNIX-system- 
like” instead. He is, of course, correct.) 
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Whatever the interface is, it simply must pro¬ 
vide a way to let a user point at another pro¬ 
cess and say, “Snapshot it,” just as we can 
stop a running job with job control. 

1003.12: Protocol-independent interfaces 

This group is still working on two separate in¬ 
terfaces to the network: Simplified Network In¬ 
terface (SNI) and Detailed Network Interface 
(DNI). The January meeting raised the possi¬ 
bility that the group would coalesce these into 
a single scheme, but that scheme seems not to 
have materialized. DNI will provide a 
familiar socket- or XTI/TLI-like interface to 
networks, while SNI will provide a simpler, 
stdio-like interface for programs that don’t 
need the level of control that DNI will pro¬ 
vide. The challenge of SNI is to make some¬ 
thing that’s simple but not so crippled that it’s 
useless. The challenge of DNI is to negotiate 
the fine line between the two competing exist¬ 
ing practices. The group has already decided 
not to use either sockets or XTI, and is look¬ 
ing at requirements for the replacement. Our 
snitch, Andy Nicholson, challenged readers to 
find a reason not to make DNI endpoints 
POSIX file descriptors, but has seen no takers. 

1003.14: Multiprocessing 

The multiprocessing group, which had been 
meeting as sort of an ad hoc spinoff of the 
real-time group, was given PAR approval at 
the April meeting as 1003.16 but quickly 
renamed 1003.14 for administrative reasons. 
They’re currently going through the standard 
set of jobs that new groups have to accom¬ 
plish, including figuring out what tasks need to 
be accomplished, whom to delegate them to, 
and how to attract enough working-group 
members to get everything done. If you want 
to get in on the ground floor of the multipro¬ 
cessing standard, come to Danvers and 
volunteer to do something. 

One thing that needs to be done is liaison 
work with other committees, many of which 
are attacking problems that bear on multipro¬ 
cessors as well. One example is dot ten’s 
checkpointing work, which I talked about ear¬ 
lier. Checkpointing is both of direct interest 
to dot fourteen, and is analogous to several 
other problems the group would like to 


address. (A side effect of the PAR prolifera¬ 
tion problem mentioned earlier is that inter- 
group coordination efforts go up as the square 
of the number of groups.) 

1201: Windows, sort of 

Okay, as a review, we went into the Utah 
meeting with one official group, 1201, and four 
unofficial groups preparing PARs: 

1. 1201.1: Application toolkit 

2. 1201.2: Recommended Practice for 

Driveability/User Portability 

3. 1201.3: User Interface Management 

Systems 

4. 1201.4: Xlib 

By the end of the week, one PAR had 
been shot down (1201.3), one approved 
(1201.2), and two remained unsubmitted. 

The 1201.4 par was deferred because the 
X consortium says Xlib is about to change 
enough that we don’t want to standardize the 
existing version. I’ll ask, “If it’s still changing 
this fast, do we want to even standardize on 
the next version?” The 1201.1 PAR was 
deferred because the group hasn’t agreed on 
what it wants to do. At the beginning of the 
week, the two major camps (OSF/Motif and 
OPEN LOOK)* had agreed to try to merge the 
two interfaces. By mid-week, they wouldn’t 
even sit at the same table. That they’d struck 
off in an alternative compromise direction by 
the end of the week speaks extremely highly of 
all involved. What the group’s looking at now 
is a toolkit at the level of XVT:* a layer over 
all of the current competing technologies that 
would provide portability without invalidating 
any existing applications. This seems like just 
the right approach. (I have to say this because 
I suggested it in an editorial about six months 
ago.) 

The 1201.3 PAR was rejected. Actually, 
1201 as a whole voted not to submit it, but the 
people working on it felt strongly enough that 


t OSF/Motif is a Registered Trademark of the Open 
Software Foundation. 

OPEN LOOK is a Registered Trademark of AT&T. 

X XVT is a trademark of XVT Software Inc. 
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they submitted it anyway. The SEC’s con¬ 
sensus was that the field wasn’t mature enough 
to warrant even a recommended practice, but 
the work should continue, perhaps as a Uni- 
Forum Technical Committee. The study 
group countered that it was important to set a 
standard before there were competing 
technologies, and that none of the attendees 
sponsoring companies would be willing to foot 
the bill for their work within anything but a 
standards body. The arguments weren’t per¬ 
suasive. 

The 1201.2 PAR, in contrast, sailed 
through. What’s interesting about this work is 
that it won’t be an API standard. A fair frac¬ 
tion of the committee members are human- 
factors people, and the person presenting the 
PAR convinced the SEC that there is now 
enough consensus in this area that a standard 
is appropriate. I’m willing to believe this, but 
I think that stretching the net of the IEEE’s 
Technical Committee on Operating Systems so 
wide that it takes in a human-factors standard 
for windowing systems is overreaching. 


X3 

There are other ANSI-accredited standards- 
sponsoring bodies in the U.S. besides the 
IEEE. The best known in our field is the 
Computer Business Equipment Manufacturers’ 
Association (CBEMA), which sponsors the X3 
efforts, recently including X3J11, the ANSI-C 
standards committee. X3Jll’s job has wound 
down; Doug Gwyn tells me that there’s so lit¬ 
tle happening of general interest that it isn’t 
worth a report. Still, there’s plenty going on in 
the X3 world. One example is X3B11, which 
is developing a standard for file systems on 
optical disks. Though this seems specialized, 
Andrew Hume suggests in his report that this 
work may eventually evolve into a standards 
effort for file systems on any read-write mass 
storage device. See the dot-four common 
reference ballot for the kind of feelings new 
file-system standards bring out. 

I encourage anyone out there on an X3 
committee who thinks the committee could 
use more user exposure and input to file a 
report. For example, Doug Gwyn suggests that 
there is enough activity in the C++ standards 
world to merit a look. If anyone out there 
wants to volunteer a report. I’d love to see it. 
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Final Printing of the 4.3BSD Manuals 


(>i<ni i< 11 >k\i 


Purchase Order #: 
Date:_ 


Pursuant to the copyright notice as found on the rear of the cover page of the UNIX® /32V 
Programmer's Manual stating that: 

"Holders of a UNIX ®/32V software license are permitted to copy 
this document, or any portion of it, as necessary for licensed 
use of the software, provided this copyright notice and statement 
of permisssion are included," 

I hereby appoint the USENIX Association as my agent, to act on my behalf to duplicate and 
provide me with such copies of the Berkeley 4.3BSD Manuals as I may request. 


Signature:____ 

The prices below include shipping (via UPS) and handling charges for domestic orders. 
Overseas postage rates will be provided upon request. 


4.3BSD User's Manual Set (3 vols) at $28.00 each = $_ 

4.3BSD Programmer's Manual Set (3 vols) _at $28.00 each = $_ 

4.3BSD System Manager's Manual (1 vol.) _at $12.00 each = $_ 

Total = $. 

Discounts are available for bulk orders. Please inquire. 


PAYMENT OPTIONS 

□ Check enclosed payable to USENIX Association. □ Purchase order enclosed. Please send an invoice. 

□ Please charge my: □ Visa CH MasterCard 

Account # Expiration Date 

Signature __ 



1/90 


Ship to: 


Bill to, if different: 


Phone #: _ 

Mail your check or purchase order with this order form to: 

USENIX Association, Manual Order Dept. 
2560 Ninth Street, Ste. 215 
Berkeley, CA 94710 
415/528-8649 


PLEASE ALLOW 2 WEEKS FOR RECEIPT OF YOUR ORDER. 
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Obtaining GNU Software 

The GNU Project (GNU’s Not UNIX) is developing a complete UNIX compatible software 
system with freely redistributable source code. The rationale for GNU is explained in the GNU Mani¬ 
festo. Copies are available in the GNU Emacs distribution and manual, and by request to 
gnu@prep.ai.mit.edu or { uunet,mit-eddie)!prep.ai.mit.edu!gnu . 

The Free Software Foundation encourages you to get GNU software from or with others. GNU 
software is also available by ftp on the DoD/NSF Internet, and by uucp from uunet and other sites. 
Ask gnu@prep for details. If you can not use one of these methods, you can use the order form on 
the next page. 

Since this article was last published in the May/June 1989 issue of ;login:, there have been 
several additions and changes to the GNU software available. The major ones are detailed in the fol¬ 
lowing paragraphs. Almost all of the other older software on the tapes have been updated to newer 
versions that are more bug free and support more UNIX systems. 

One new manual has been published documenting GNU Emacs Lisp. 

The Beta Test tape has been re-named the Pre-Release tape. It will contain software that is 
becoming stable, such as version 1 of GCC. A new Experimental tape will be available late this 
year. It will contain software being actively developed, such as version 2 of GCC and version 19 
of GNU Emacs. Added to the GNU Pre-Release tape are: 

The GNU Shell, Bash (for Bourne Again SHell), provides compatibility with the UNIX sh. 
It provides many extensions found in csh and ksh. It has job control, cs/j-style command 
history, command-line editing (with Emacs and vi modes built-in) and the ability to rebind 
keys). 

GNU versions of file manipulation utilities including Is, mv, cp, cat, rm, du, head, tail, cmp, 
chmod, mkdir, and In. 

f2c, a FORTRAN to C translator. 

COFF support for the GNU compilers and object file utilities. 

RCS, the Revision Control System, for version control and management of large software 
projects. 

CVS, the Concurrent Version System, manages software revision and release control in a 
multi-developer, multi-directory, multi-group environment. 

GnuGo allows the user to play the machine in a game of Go (Wei-Chi). It is an updated 
version of the program called Hugo. 

Due to the increase in size of X11R4, the X Window System is now distributed on two tapes. 
XI1R3 had been on one tape. 

X10R4 of the X Window System has been removed from the Emacs tape as it is no longer sup¬ 
ported by MIT. 

Many of the programs in the GNU Software distribution are covered by the GNU General Public 
License that permits everyone to have and run copies of them, at no charge, and to redistribute 
copies under certain conditions designed to make sure that that all modified versions remain as free 
as the versions GNU distributes. The License is usually in a file named COPYING. 

The USENIX Association is printing this information as a service to the user community; no endorse¬ 
ment of GNU software is implied. 
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GNU Software Order Form 

Prices are subject to change without notice after January 1991. All software and publications are 
distributed with permission to copy and to redistribute. TeX source for each manual is on the 
appropriate tape. All software is provided on an “as is” basis, with no warranty of any kind. 

For UNIX systems, on 1600 bpi 9-track tape in UNIX tar format: 


_at $ 150 = $_ GNU Emacs source code & other software. Includes T, Scheme, Bison, Hack, GNU 

Chess, GDB. 

_at $ 150 = $_ GNU Pre-Release software: the C compiler, G++, Bash, Bison, Flex, Ghostscript, 

Gawk, the GNU Assembler, Gnuplot, Compress, object & general file utilities, 
Make, Diff, Grep, Tar, freed 4.3BSD-Tahoe files. 

_at $ 150 = $_ Required MIT X Window System V11R4: core software & documentation, 

contributed client software. 

at $ 150 = $_ Optional MIT X Window System V11R4: contributed software: libraries, games, 

Andrew & other toolkits, etc. 

For Suns & other UNIX systems, on QIC-24 DC300XLP 1/4 " cartridge tape, UNIX tar format: 

_at $ 175 = $_ GNU Emacs & other software, as in the first item. 

_at $ 175 = $_ GNU Pre-release software, as in the second item. 

_at $ 175 = $_ Required X V11R4, as in the third item. 

_at $ 175 = $_ Optional X V11R4, as in the fourth item. 

For VMS systems, on 1600 bpi 9-track tape, VMS BACKUP format: 

_at $ 150 = $_ GNU Emacs source code & binaries. 

_at $ 150 - $_ GNU C Compiler source code & binaries, Bison & GAS. 

GNU Emacs manual, ~300 pages, phototypeset, offset-printed, spiral-bound, with a reference card. 

at $ 15 = $_ A single GNU Emacs manual. 

at $ 60 = $_ A box of six GNU Emacs manuals. 

The following documentation: 

__ at $ 1 = $_ GNU Emacs reference card, without the manual. 

_at $ 5 = $ „__ Packet of ten GNU Emacs reference cards. 

__at $ 50 = $ __ GNU Emacs Lisp Reference manual, "550 pages. 

__at $ 10 = $ ___ GDB manual, "70 pages, side stapled. 

_at $ 10 = $ ___ Texinfo manual, "100 pages, side stapled. 

_at $ 10 = $ ___ Termcap manual, "60 pages, side stapled. 

__ at $ 10 = $_ Bison manual," 90 pages, side stapled. 

_at $ 10 = $_ Gawk manual, "150 pages, side stapled. 

_at $ 10 = $_ Make manual, "120 pages, side stapled. 

Sub Total $ __ w 

+ $ ___ If ordering from Massachusetts: please add 5% sales tax. 

+ $ _____ If outside of North America & Hawaii, for shipping costs: 

+ $ __for tapes or unboxed manuals, please add $15, and then add $15 more for each 

tape or unboxed manual in the order: total for this item = $ 15 + $ 15n; 

+ $ ______ for each box of Emacs manuals, please add $60. 

+ $ - Optional tax-deductible donation. 

Total $ __ Orders are filled upon receipt of check or money order. 


Please make checks payable to the “Free Software Foundation,” and mail orders to: 

Free Software Foundation Name:_______ 

675 Mass. Avenue Organization: ______ 

Cambridge, MA 02139 Street Address: _______ 

+ 1 (617) 876-3296 City, State, Zip: _______ 
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Local User Groups 

The Association will support local user groups by doing a mailing to assist the formation of a 
new group and publishing information on local groups in ;login:. At least one member of the group 
must be a current member of the Association. Send additions and corrections to login@usenix.org . 


CA - Fresno: the Central California UNIX Users 
Group consists of a uwcp-based electronic mailing 
list to which members may post questions or infor¬ 
mation. For connection information: 

Educational and governmental institutions: 

Brent Auemheimer (209) 294-4373 

brent@CSUFresno.edu or csufreslbrent 

Commercial institutions or individuals: 

Gordon Crumal (209) 875-8755 

csufreslgordon (209) 298-8393 


CA - Irvine: the UNIX Users Association of 
Southern California meets the 2 nd Monday of each 
month. 

Rich Bergstedt, AT&T (714) 727-5231 

8001 Irvine Center Dr., Suite 224 
Irvine, CA 92718-2900 

UUASC Information Line (714) 727-5232 

CO - Boulder: the Front Range UNIX Users Group 
meets monthly at different sites. 

Steve Gaede gaede@sda.com 

Software Design & Analysis (303) 499-4782 

P.O. Box 3521 
Boulder, CO 80303 


FL - Coral Springs: 

S. Shaw McQuinn (305) 344-8686 

8557 W. Sample Road 
Coral Springs, FL 33065 


FL - Fort Lauderdale/Miami: The South Florida 
UNIX Users Group meets the 2 nd Tuesday of each 
month. 

Tony Vincent, John McLaughlin (305) 776-7770 
{sun,novavax,gould} !sunvice!tony 
j mclaughlin@sun. com 

John O’Brien (305) 475-7633 

gatech! uflorida! novavax!j ohn 


FL - Jacksonville/Northeast: UNIX Users of Jack¬ 
sonville meets the 2 nd Thursday of each month. 

Tom Blakely (904) 646-2820 

uflorida!unf7!tfb 

Emilie Olsen (904) 390-3621 


FL - Melbourne: the Space Coast UNIX Users 
Group meets at 8pm on the 3 rd Wednesday of each 
month at the Florida Institute of Technology. 


Bill Davis (407) 242-4449 

bill@ccd.harris.com 


FL - Orlando: the Central Florida UNIX Users 
Group meets the 3 rd Thursday of each month. 

Mike Geldner (407) 862-0949 

codas!sunfla!mike 

Ben Goldfarb (407) 275-2790 

goldfarb@hcx9. ucf. edu 

Mikel Manitius (407) 869-2462 

{codas, attmail) Imikel 


FL - Tampa Bay: the Tampa UNIX Users Group 
meets the l sl Thursday of each month in Largo. 

Bill Hargen (813) 530-8655 

uunet!pdn!hargen 

George W. Leach (813) 530-2376 

uunet!pdn!reggie 


GA - Atlanta: meets on the 1 st Monday of each 
month in White Hall, Emory University. 

Atlanta UNIX Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 

Marc Merlin (404) 442-4772 

Mark Landry (404) 365-8108 


MI - Detroit/Ann Arbor: The SouthEastem Mich¬ 
igan Sun Local Users Group meets jointly with the 
Nameless UNIX Group on the 2 nd Thursday of each 
month in Ann Arbor. 

Steve Simmons home: (313) 426-8981 

scs@lokkur.dexter.mi.us office: (313) 769-4086 

K. Richard McGill Bill Bulley 

rich@sendai.ann-arbor.mi.us web@applga.uucp 


MI - Detroit/Ann Arbor: dinner meetings the 1 st 
Wednesday of each month. 

Linda Mason (313) 855-4220 

michiganl/usr/group 

P.O. Box 189602 

Farmington Hills, MI 48018-9602 


MN - Minneapolis/St. Paul: meets the 1 st Wednes¬ 
day of each month. 

UNIX Users of Minnesota Robert A. Monio 

17130 Jordan Court pnessutt@nis.mn.org 

Lakeville, MN 55044 (612) 895-7007 
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MO - St. Louis: 

St. Louis UNIX Users Group 
Plus Five Computer Services 
765 Westwood, 10A 
Clayton, MO 63105 


Eric Kiebler 
plus5!sluug 
(314) 725-9492 


G. Baun, UNIX SIG rutgers!{bpa,cbmvax}! 

do PACS temvaxlpacsbb! {gbaun,whutchi} 

Box 312 

La Salle University 
Philadelphia, PA 19141 


NE - Omaha: meets the 2 nd Thursday of each 
month. 

/usr/group nebraska Kent Landfield 

P.O. Box 44112 kent@ugn.uucp 

Omaha, NE 68144 (402) 291-8300 


New England - Northern: meets monthly at differ¬ 
ent sites. 

Peter Schmitt 

Peter.Schmitt@dartvax!dartmouth.edu 
Kiewit Computation Center (603) 646-2085 

Dartmouth College 
Hanover, NH 03755 


NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Pat Parseghian pep@Princeton.EDU 

Dept, of Computer Science (609) 452-6261 

Princeton University 
Princeton, NJ 08544 


NY - New York City: Unigroup of New York City 
meets every other month in Manhattan. 

Unigroup of New York City 
G.P.O. Box 1931 
New York, NY 10116 

Peter Gutmann (212) 618-0973 

peterg@murphy.com 


OH - Columbus: The Columbus Local UNIX 
Group meets the l sl Monday of each month. 

Mark Verber verber@mps.ohio-state.edu 

Physics Department (614) 292-8002 

Ohio State University 
Columbus, OH 43210 


OK - Tulsa: the Tulsa UNIX Users Group, $USR, 
meets the 2nd Wednesday of each month. 

Stan Mason (918) 560-5329 

tulsix!smason@drd.com 

Mark Lawrence (918) 743-3013 

mark@drd.com 


PA - Philadelphia: the UNIX SIG of the Philadel¬ 
phia Area Computer Society meets the morning of 
the 3rd Saturday of each month. 


TX - Austin: CACTUS meets the 3 rd Thursday of 
each month. 

Capital Area Central Texas UNIX Society 
P.O. Box 9786 
Austin, TX 78766-9786 

officers@peyote.cactus.org 

James Johnson (512) 331-3781 

jjhnsn@cs.utexas.edu 


TX - Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
Seny Systems, Inc. 

5327 N. Central, #320 
Dallas, TX 75205 

Jim Hummel (214) 522-2324 


TX - Houston: the Houston UNIX Users Group 
(Hounix) meets the 3 rd Tuesday of each month. 

Hounix answering machine (713) 684-6590 

Bob Marcum, president (713) 270-8124 

Chuck Bentley, vice-president (713) 789-8928 

chuckb@hounix.uucp 

TX - San Antonio: the San Antonio UNIX Users 
meets the 3 rd Thursday of each month. 

Jeff Mason gatech!petro!hpsatb!jeff 

Hewlett Packard (512) 494-9336 

14100 San Pedro 
San Antonio, TX 78232 


WA - Seattle: meets monthly. 

Bill Campbell (206) 232-4164 

Seattle UNIX Group Membership Information 
P.O. Box 820 

Mercer Island, WA 98040-0820 
uw-beaver!tikal!camco!bill 


Washington, D.C.: meets the l sl Tuesday of each 
month. 

Washington Area UNIX Users Group 
2070 Chain Bridge Road, Suite 350 
Vienna, VA 22182 

Alan Fedder (703) 448-1908 


CANADA - Toronto: 

Evan Leibovitch (416) 452-0504 

143 Baronwood Court evan@telly.on.ca 

Brampton, Ont. Canada L6V 3H8 
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